From rucus-bounces@ietf.org Fri Feb 15 02:42:16 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7713A6A1A; Fri, 15 Feb 2008 02:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.087 X-Spam-Level: X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK4FEGist33j; Fri, 15 Feb 2008 02:42:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC483A695E; Fri, 15 Feb 2008 02:42:15 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C5B3A69DD for ; Fri, 15 Feb 2008 02:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTgL51IWOLrd for ; Fri, 15 Feb 2008 02:32:33 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 9B1863A6808 for ; Fri, 15 Feb 2008 02:32:33 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 27990798 for rucus@ietf.org; Fri, 15 Feb 2008 10:33:53 +0000 Mime-Version: 1.0 (Apple Message framework v753) To: rucus@ietf.org Message-Id: <32E96743-BE8E-49CB-B6F2-AB5B54736627@voxeo.com> From: Dan York Date: Fri, 15 Feb 2008 05:33:52 -0500 X-Mailer: Apple Mail (2.753) X-Mailman-Approved-At: Fri, 15 Feb 2008 02:42:15 -0800 Subject: [Rucus] Welcome to the RUCUS mailing list! X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1126362980==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1126362980== Content-Type: multipart/alternative; boundary=Apple-Mail-10--721350647 --Apple-Mail-10--721350647 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Welcome to the RUCUS mailing list for the "Reducing Unwanted Communications Using SIP" BOF to be held at IETF 71 in Philadelphia (Mar 10-14). More information about the BOF can be found at: http://www.tschofenig.priv.at/bof-rucus.html Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-10--721350647 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Welcome to the RUCUS mailing list for the "Reducing Unwanted = Communications Using SIP" BOF to be held at IETF 71 in Philadelphia (Mar = 10-14). =A0More information about the BOF can be found at:


Regards,
Dan
=

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-10--721350647-- --===============1126362980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1126362980==-- From rucus-bounces@ietf.org Fri Feb 15 04:39:56 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00FF128C835; Fri, 15 Feb 2008 04:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.005 X-Spam-Level: X-Spam-Status: No, score=-0.005 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwlX1afstwJJ; Fri, 15 Feb 2008 04:39:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F83B3A6A88; Fri, 15 Feb 2008 04:39:55 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA9C3A6A92 for ; Fri, 15 Feb 2008 04:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6blc-pBAjzE for ; Fri, 15 Feb 2008 04:32:54 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2EB503A6A6E for ; Fri, 15 Feb 2008 04:32:54 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id CBC222C000357; Fri, 15 Feb 2008 13:34:14 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEn9BmGATTHO; Fri, 15 Feb 2008 13:34:14 +0100 (CET) Received: by smtp0.neclab.eu (Postfix, from userid 1001) id B08252C009E8F; Fri, 15 Feb 2008 13:34:14 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id D9A7F2C000357; Fri, 15 Feb 2008 13:34:03 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 13:34:03 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0E8C@mx1.office> In-Reply-To: <791986B7-17E1-4C4E-8B74-D61BA2138D2F@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] FYI - RUCUS mailing list is now live - please subscribeso we can move SPIT conversation there Thread-Index: Achvv5PsJYJAmn0BTAS2RfRsUEkJ5wADynWw References: <20080130165615.GA2033@nic.at><47A2C56E.2030909@gmx.net><20080209221108.GA11031@nic.at><47AF6103.7070803@cisco.com> <20080211121826.GA13635@nic.at><5F6519BF2DE0404D99B7C75607FF76FF4D0C05@mx1.office><08A7BA4E-07D3-4FCA-9569-4A3C4C8C5C26@voxeo.com> <791986B7-17E1-4C4E-8B74-D61BA2138D2F@voxeo.com> From: "Saverio Niccolini" To: "Signaling TO Prevent SPIT" X-Sanitizer: This message has been sanitized! X-Mailman-Approved-At: Fri, 15 Feb 2008 04:39:54 -0800 Cc: rucus@ietf.org Subject: Re: [Rucus] [spitstop] FYI - RUCUS mailing list is now live - please subscribeso we can move SPIT conversation there X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dan, it is fine to move discussion over RUCUS but as I said, SPITSTOP has now about 100 people registered, does it makes sense to move now (3 weeks before IETF 71)? It doesnot help if we have discussion on RUCUS among 5 people because all the others still need to register (and it takes time...) Having said that, I have put RUCUS mailing list in CC to start it over there as well... Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: spitstop-bounces@listserv.netlab.nec.de > [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of Dan York > Sent: Friday, February 15, 2008 11:43 AM > To: Signaling TO Prevent SPIT; SIPPING LIST > Subject: [spitstop] FYI - RUCUS mailing list is now live - > please subscribeso we can move SPIT conversation there > > SIPPING and SPITSTOP members, > > FYI, the RUCUS mailing list is now live at: > > http://www.ietf.org/mailman/listinfo/rucus > > Please join that mailing list so that we can plan for the > upcoming BOF in Philadelphia. > > Thanks, > Dan > > P.S. If you aren't familiar with the RUCUS BoF, here is the > approved request: http://www.tschofenig.priv.at/bof-rucus.html > This is "Reducing Unwanted Communication Using SIP" and is > designed to look at architectural issues involved with > preventing voice spam, aka Spam for Internet Telephony aka SPIT. > > > On Feb 14, 2008, at 10:57 AM, Dan York wrote: > > > > On Feb 12, 2008, at 11:25 PM, Saverio Niccolini wrote: > > > -- as Cullen suggested, until the RUCUS mailing > list is up and running, > please use SPITSTOP mailing list for > discussions related to this > (avoid cross posting as I just did) > > > On this point, I'll just mention that the RUCUS mailing > list was requested back when Cullen sent out his note but > seems to be hung up in the Secretariat transition and we are > still waiting for the list to be created. > > Regards, > Dan > > > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 04:39:56 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249D228D003; Fri, 15 Feb 2008 04:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=-1.605, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voNB48LVNfd0; Fri, 15 Feb 2008 04:39:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A88E3A6AAD; Fri, 15 Feb 2008 04:39:55 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6F43A6A92 for ; Fri, 15 Feb 2008 04:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp2gQUfBAqnS for ; Fri, 15 Feb 2008 04:37:13 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 138223A6AAF for ; Fri, 15 Feb 2008 04:37:12 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1FCcUUr026151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2008 13:38:31 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1FCcSGQ005598; Fri, 15 Feb 2008 13:38:30 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Feb 2008 13:38:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 13:38:29 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB79823E@DEMUEXC012.nsn-intra.net> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0E8C@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] FYI - RUCUS mailing list is now live - pleasesubscribeso we can move SPIT conversation there Thread-Index: Achvv5PsJYJAmn0BTAS2RfRsUEkJ5wADynWwAAAwEVA= References: <20080130165615.GA2033@nic.at><47A2C56E.2030909@gmx.net><20080209221108.GA11031@nic.at><47AF6103.7070803@cisco.com><20080211121826.GA13635@nic.at><5F6519BF2DE0404D99B7C75607FF76FF4D0C05@mx1.office><08A7BA4E-07D3-4FCA-9569-4A3C4C8C5C26@voxeo.com><791986B7-17E1-4C4E-8B74-D61BA2138D2F@voxeo.com> <5F6519BF2DE0404D99B7C75607FF76FF4D0E8C@mx1.office> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "Signaling TO Prevent SPIT" X-OriginalArrivalTime: 15 Feb 2008 12:38:31.0044 (UTC) FILETIME=[ABBFB440:01C86FCF] X-Mailman-Approved-At: Fri, 15 Feb 2008 04:39:54 -0800 Cc: rucus@ietf.org Subject: Re: [Rucus] [spitstop] FYI - RUCUS mailing list is now live - pleasesubscribeso we can move SPIT conversation there X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Let us do a batch registration of the folks subscribed to the SPITSTOP mail= ing list to the RUCUS mailing list. = Dan could do that since he has the admin passwd. = You, Saverio, need to send him the mail addresses. = Ciao Hannes = > -----Urspr=FCngliche Nachricht----- > Von: spitstop-bounces@listserv.netlab.nec.de = > [mailto:spitstop-bounces@listserv.netlab.nec.de] Im Auftrag = > von ext Saverio Niccolini > Gesendet: Freitag, 15. Februar 2008 14:34 > An: Signaling TO Prevent SPIT > Cc: rucus@ietf.org > Betreff: Re: [spitstop] FYI - RUCUS mailing list is now live = > - pleasesubscribeso we can move SPIT conversation there > = > Dan, > = > it is fine to move discussion over RUCUS but as I said, = > SPITSTOP has now about 100 people registered, does it makes sense = > to move now (3 weeks before IETF 71)? > It doesnot help if we have discussion on RUCUS among 5 people = > because all the others still need to register (and it takes time...) > = > Having said that, I have put RUCUS mailing list in CC to = > start it over there > as well... > = > Saverio > = > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division = > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > = > = > = > > -----Original Message----- > > From: spitstop-bounces@listserv.netlab.nec.de = > > [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf = > Of Dan York > > Sent: Friday, February 15, 2008 11:43 AM > > To: Signaling TO Prevent SPIT; SIPPING LIST > > Subject: [spitstop] FYI - RUCUS mailing list is now live - = > > please subscribeso we can move SPIT conversation there > > = > > SIPPING and SPITSTOP members, > > = > > FYI, the RUCUS mailing list is now live at: > > = > > http://www.ietf.org/mailman/listinfo/rucus > > = > > Please join that mailing list so that we can plan for the = > > upcoming BOF in Philadelphia. > > = > > Thanks, > > Dan > > = > > P.S. If you aren't familiar with the RUCUS BoF, here is the = > > approved request: http://www.tschofenig.priv.at/bof-rucus.html = > > This is "Reducing Unwanted Communication Using SIP" and is = > > designed to look at architectural issues involved with = > > preventing voice spam, aka Spam for Internet Telephony aka SPIT. > > = > > = > > On Feb 14, 2008, at 10:57 AM, Dan York wrote: > > = > > = > > = > > On Feb 12, 2008, at 11:25 PM, Saverio Niccolini wrote: > > = > > = > > -- as Cullen suggested, until the RUCUS mailing = > > list is up and running, > > please use SPITSTOP mailing list for = > > discussions related to this > > (avoid cross posting as I just did) > > = > > = > > On this point, I'll just mention that the RUCUS mailing = > > list was requested back when Cullen sent out his note but = > > seems to be hung up in the Secretariat transition and we are = > > still waiting for the list to be created. > > = > > Regards, > > Dan > > = > > = > > = > > -- > > Dan York, CISSP, Director of Emerging Communication Technology > > Office of the CTO Voxeo Corporation dyork@voxeo.com > > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > = > > Bring your web applications to the phone. > > Find out how at http://evolution.voxeo.com > > = > > = > > = > > = > > = > _______________________________________________ > spitstop mailing list > spitstop@listserv.netlab.nec.de > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > = _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 04:41:16 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C735F28CE9A; Fri, 15 Feb 2008 04:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu8vRgTE1sDD; Fri, 15 Feb 2008 04:41:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0A0F3A6A90; Fri, 15 Feb 2008 04:41:15 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C44C3A6A90 for ; Fri, 15 Feb 2008 04:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfQPDTt4G12K for ; Fri, 15 Feb 2008 04:41:13 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 001113A6A92 for ; Fri, 15 Feb 2008 04:41:12 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 9D04B2C000357; Fri, 15 Feb 2008 13:42:33 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KohKkbdxKKpu; Fri, 15 Feb 2008 13:42:33 +0100 (CET) Received: by smtp0.neclab.eu (Postfix, from userid 1001) id 80CE22C00C336; Fri, 15 Feb 2008 13:42:33 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 1DA722C000357; Fri, 15 Feb 2008 13:42:23 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 15 Feb 2008 13:40:20 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0E94@mx1.office> In-Reply-To: <5FB585F183235B42A9E70095055136FB79823E@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] FYI - RUCUS mailing list is now live -pleasesubscribeso we can move SPIT conversation there Thread-Index: Achvv5PsJYJAmn0BTAS2RfRsUEkJ5wADynWwAAAwEVAAABaFUA== References: DEFANGED[6209]:DEFANGED[1]:<20080130165615.GA2033@nic.at><47A2C56E.2030909@gmx.net><20080209221108.GA11031@nic.at><47AF6103.7070803@cisco.com><20080211121826.GA13635@nic.at><5F6519BF2DE0404D99B7C75607FF76FF4D0C0 " " 5@mx1.office " " ><08A7BA4E-07D3-4FCA-9569-4A3C4C8C5C26@voxeo.com><791986B7-17E1-4C4E-8B74-D61BA2138D2F@voxeo.com><5F6519BF2DE0404D99B7C75607FF76FF4D0E8C@mx1.office> <5FB585F183235B42A9E70095055136FB79823E@DEMUEXC012.nsn-intra.net> From: "Saverio Niccolini" To: "Signaling TO Prevent SPIT" X-Sanitizer: This message has been sanitized! MIME-Version: 1.0 Cc: rucus@ietf.org Subject: Re: [Rucus] [spitstop] FYI - RUCUS mailing list is now live -pleasesubscribeso we can move SPIT conversation there X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Not sure all the people wants that, as admin of SPITSTOP I am not feeling allowed to decide for people... Saverio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division = Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 = = > -----Original Message----- > From: spitstop-bounces@listserv.netlab.nec.de = > [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of = > Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Friday, February 15, 2008 1:38 PM > To: Signaling TO Prevent SPIT > Cc: rucus@ietf.org > Subject: Re: [spitstop] FYI - RUCUS mailing list is now live = > -pleasesubscribeso we can move SPIT conversation there > = > Let us do a batch registration of the folks subscribed to the = > SPITSTOP mailing list to the RUCUS mailing list. = > = > Dan could do that since he has the admin passwd. = > You, Saverio, need to send him the mail addresses. = > = > Ciao > Hannes > = > = > > -----Urspr=FCngliche Nachricht----- > > Von: spitstop-bounces@listserv.netlab.nec.de > > [mailto:spitstop-bounces@listserv.netlab.nec.de] Im Auftrag von ext = > > Saverio Niccolini > > Gesendet: Freitag, 15. Februar 2008 14:34 > > An: Signaling TO Prevent SPIT > > Cc: rucus@ietf.org > > Betreff: Re: [spitstop] FYI - RUCUS mailing list is now live > > - pleasesubscribeso we can move SPIT conversation there > > = > > Dan, > > = > > it is fine to move discussion over RUCUS but as I said, = > SPITSTOP has = > > now about 100 people registered, does it makes sense to move now (3 = > > weeks before IETF 71)? > > It doesnot help if we have discussion on RUCUS among 5 = > people because = > > all the others still need to register (and it takes time...) > > = > > Having said that, I have put RUCUS mailing list in CC to = > start it over = > > there as well... > > = > > Saverio > > = > > = > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Dr. Saverio Niccolini > > Senior Researcher > > NEC Laboratories Europe, Network Research Division = > > Kurfuerstenanlage 36, D-69115 Heidelberg > > Tel. +49 (0)6221 4342-118 > > Fax: +49 (0)6221 4342-155 > > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, = > > London W3 6BL Registered in England 2832014 > > = > > = > > = > > > -----Original Message----- > > > From: spitstop-bounces@listserv.netlab.nec.de > > > [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf > > Of Dan York > > > Sent: Friday, February 15, 2008 11:43 AM > > > To: Signaling TO Prevent SPIT; SIPPING LIST > > > Subject: [spitstop] FYI - RUCUS mailing list is now live - please = > > > subscribeso we can move SPIT conversation there > > > = > > > SIPPING and SPITSTOP members, > > > = > > > FYI, the RUCUS mailing list is now live at: > > > = > > > http://www.ietf.org/mailman/listinfo/rucus > > > = > > > Please join that mailing list so that we can plan for the = > upcoming = > > > BOF in Philadelphia. > > > = > > > Thanks, > > > Dan > > > = > > > P.S. If you aren't familiar with the RUCUS BoF, here is = > the approved = > > > request: http://www.tschofenig.priv.at/bof-rucus.html > > > This is "Reducing Unwanted Communication Using SIP" and = > is designed = > > > to look at architectural issues involved with preventing = > voice spam, = > > > aka Spam for Internet Telephony aka SPIT. > > > = > > > = > > > On Feb 14, 2008, at 10:57 AM, Dan York wrote: > > > = > > > = > > > = > > > On Feb 12, 2008, at 11:25 PM, Saverio Niccolini wrote: > > > = > > > = > > > -- as Cullen suggested, until the RUCUS mailing = > list is up and = > > > running, > > > please use SPITSTOP mailing list for = > discussions related to this > > > (avoid cross posting as I just did) > > > = > > > = > > > On this point, I'll just mention that the RUCUS mailing = > > > list was requested back when Cullen sent out his note but = > > > seems to be hung up in the Secretariat transition and we are = > > > still waiting for the list to be created. > > > = > > > Regards, > > > Dan > > > = > > > = > > > = > > > -- > > > Dan York, CISSP, Director of Emerging Communication Technology > > > Office of the CTO Voxeo Corporation dyork@voxeo.com > > > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > > > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > > = > > > Bring your web applications to the phone. > > > Find out how at http://evolution.voxeo.com > > > = > > > = > > > = > > > = > > > = > > _______________________________________________ > > spitstop mailing list > > spitstop@listserv.netlab.nec.de > > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > > = > _______________________________________________ > spitstop mailing list > spitstop@listserv.netlab.nec.de > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > = _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 04:50:26 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2CD28D003; Fri, 15 Feb 2008 04:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdyxmCJxKx3M; Fri, 15 Feb 2008 04:50:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338BF3A6A88; Fri, 15 Feb 2008 04:50:25 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E02728C418 for ; Fri, 15 Feb 2008 04:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PrqrRRbdAXO for ; Fri, 15 Feb 2008 04:50:22 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CD9303A6A88 for ; Fri, 15 Feb 2008 04:50:21 -0800 (PST) Received: (qmail invoked by alias); 15 Feb 2008 12:51:40 -0000 Received: from proxy4-nsn.nsn-inter.net (EHLO [217.115.75.232]) [217.115.75.232] by mail.gmx.net (mp056) with SMTP; 15 Feb 2008 13:51:40 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ESTgsa+XEeesS3d+SOQULREI2AD8ASwK0FKwvRS xXJreGIRs2wHxh Message-ID: <47B58AD7.4020302@gmx.net> Date: Fri, 15 Feb 2008 14:51:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Saverio Niccolini References: DEFANGED[6209]:DEFANGED[1]:<20080130165615.GA2033@nic.at><47A2C56E.2030909@gmx.net><20080209221108.GA11031@nic.at><47AF6103.7070803@cisco.com><20080211121826.GA13635@nic.at><5F6519BF2DE0404D99B7C75607FF76FF4D0C0 " " 5@mx1.office " " ><08A7BA4E-07D3-4FCA-9569-4A3C4C8C5C26@voxeo.com><791986B7-17E1-4C4E-8B74-D61BA2138D2F@voxeo.com><5F6519BF2DE0404D99B7C75607FF76FF4D0E8C@mx1.office> <5FB585F183235B42A9E70095055136FB79823E@DEMUEXC012.nsn-intra.net> <5F6519BF2DE0404D99B7C75607FF76FF4D0E94@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0E94@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org, Signaling TO Prevent SPIT Subject: Re: [Rucus] [spitstop] FYI - RUCUS mailing list is now live -pleasesubscribeso we can move SPIT conversation there X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org I did the same twice already. Once with the emergency services mailing = list (ECRIT now) and then with the key provisioning mailing list = (KEYPROV now). Folks are obviously interested in this topic since = otherwise they would not have registered to the SPITSTOP mailing list in = the first place. I would have problems moving the SIPPING list over here. Saverio Niccolini wrote: > Not sure all the people wants that, as admin of SPITSTOP > I am not feeling allowed to decide for people... > > Saverio > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division = > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > = > = > > = >> -----Original Message----- >> From: spitstop-bounces@listserv.netlab.nec.de = >> [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of = >> Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Friday, February 15, 2008 1:38 PM >> To: Signaling TO Prevent SPIT >> Cc: rucus@ietf.org >> Subject: Re: [spitstop] FYI - RUCUS mailing list is now live = >> -pleasesubscribeso we can move SPIT conversation there >> >> Let us do a batch registration of the folks subscribed to the = >> SPITSTOP mailing list to the RUCUS mailing list. = >> >> Dan could do that since he has the admin passwd. = >> You, Saverio, need to send him the mail addresses. = >> >> Ciao >> Hannes >> = >> >> = >>> -----Urspr=FCngliche Nachricht----- >>> Von: spitstop-bounces@listserv.netlab.nec.de >>> [mailto:spitstop-bounces@listserv.netlab.nec.de] Im Auftrag von ext = >>> Saverio Niccolini >>> Gesendet: Freitag, 15. Februar 2008 14:34 >>> An: Signaling TO Prevent SPIT >>> Cc: rucus@ietf.org >>> Betreff: Re: [spitstop] FYI - RUCUS mailing list is now live >>> - pleasesubscribeso we can move SPIT conversation there >>> >>> Dan, >>> >>> it is fine to move discussion over RUCUS but as I said, = >>> = >> SPITSTOP has = >> = >>> now about 100 people registered, does it makes sense to move now (3 = >>> weeks before IETF 71)? >>> It doesnot help if we have discussion on RUCUS among 5 = >>> = >> people because = >> = >>> all the others still need to register (and it takes time...) >>> >>> Having said that, I have put RUCUS mailing list in CC to = >>> = >> start it over = >> = >>> there as well... >>> >>> Saverio >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Dr. Saverio Niccolini >>> Senior Researcher >>> NEC Laboratories Europe, Network Research Division = >>> Kurfuerstenanlage 36, D-69115 Heidelberg >>> Tel. +49 (0)6221 4342-118 >>> Fax: +49 (0)6221 4342-155 >>> e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, = >>> London W3 6BL Registered in England 2832014 >>> = >>> = >>> >>> = >>>> -----Original Message----- >>>> From: spitstop-bounces@listserv.netlab.nec.de >>>> [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf >>>> = >>> Of Dan York >>> = >>>> Sent: Friday, February 15, 2008 11:43 AM >>>> To: Signaling TO Prevent SPIT; SIPPING LIST >>>> Subject: [spitstop] FYI - RUCUS mailing list is now live - please = >>>> subscribeso we can move SPIT conversation there >>>> >>>> SIPPING and SPITSTOP members, >>>> >>>> FYI, the RUCUS mailing list is now live at: >>>> >>>> http://www.ietf.org/mailman/listinfo/rucus >>>> >>>> Please join that mailing list so that we can plan for the = >>>> = >> upcoming = >> = >>>> BOF in Philadelphia. >>>> >>>> Thanks, >>>> Dan >>>> >>>> P.S. If you aren't familiar with the RUCUS BoF, here is = >>>> = >> the approved = >> = >>>> request: http://www.tschofenig.priv.at/bof-rucus.html >>>> This is "Reducing Unwanted Communication Using SIP" and = >>>> = >> is designed = >> = >>>> to look at architectural issues involved with preventing = >>>> = >> voice spam, = >> = >>>> aka Spam for Internet Telephony aka SPIT. >>>> >>>> >>>> On Feb 14, 2008, at 10:57 AM, Dan York wrote: >>>> >>>> >>>> >>>> On Feb 12, 2008, at 11:25 PM, Saverio Niccolini wrote: >>>> >>>> >>>> -- as Cullen suggested, until the RUCUS mailing = >>>> = >> list is up and = >> = >>>> running, >>>> please use SPITSTOP mailing list for = >>>> = >> discussions related to this >> = >>>> (avoid cross posting as I just did) >>>> >>>> >>>> On this point, I'll just mention that the RUCUS mailing = >>>> list was requested back when Cullen sent out his note but = >>>> seems to be hung up in the Secretariat transition and we are = >>>> still waiting for the list to be created. >>>> >>>> Regards, >>>> Dan >>>> >>>> >>>> >>>> -- >>>> Dan York, CISSP, Director of Emerging Communication Technology >>>> Office of the CTO Voxeo Corporation dyork@voxeo.com >>>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>>> >>>> Bring your web applications to the phone. >>>> Find out how at http://evolution.voxeo.com >>>> >>>> >>>> >>>> >>>> >>>> = >>> _______________________________________________ >>> spitstop mailing list >>> spitstop@listserv.netlab.nec.de >>> https://listserv.netlab.nec.de/mailman/listinfo/spitstop >>> >>> = >> _______________________________________________ >> spitstop mailing list >> spitstop@listserv.netlab.nec.de >> https://listserv.netlab.nec.de/mailman/listinfo/spitstop >> >> = > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > = _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 04:55:32 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F3A3A6ABC; Fri, 15 Feb 2008 04:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.817 X-Spam-Level: X-Spam-Status: No, score=0.817 tagged_above=-999 required=5 tests=[AWL=-1.435, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, MIME_QP_LONG_LINE=1.396, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw0MZ1YBVdoL; Fri, 15 Feb 2008 04:55:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD763A6A88; Fri, 15 Feb 2008 04:55:30 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7D13A6A9A for ; Fri, 15 Feb 2008 04:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v33rGx6xCnlc for ; Fri, 15 Feb 2008 04:55:27 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 109A13A6AA5 for ; Fri, 15 Feb 2008 04:55:26 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 27991595; Fri, 15 Feb 2008 12:56:45 +0000 In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0E94@mx1.office> References: DEFANGED[6209]:DEFANGED[1]:<20080130165615.GA2033@nic.at><47A2C56E.2030909@gmx.net><20080209221108.GA11031@nic.at><47AF6103.7070803@cisco.com><20080211121826.GA13635@nic.at><5F6519BF2DE0404D99B7C75607FF76FF4D0C0 " " 5@mx1.office " " ><08A7BA4E-07D3-4FCA-9569-4A3C4C8C5C26@voxeo.com><791986B7-17E1-4C4E-8B74-D61BA2138D2F@voxeo.com><5F6519BF2DE0404D99B7C75607FF76FF4D0E8C@mx1.office> <5FB585F183235B42A9E70095055136FB79823E@DEMUEXC012.nsn-intra.net> <5F6519BF2DE0404D99B7C75607FF76FF4D0E94@mx1.office> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <5A3C0727-0BDB-447E-97BC-1FCD874ECC57@voxeo.com> From: Dan York Date: Fri, 15 Feb 2008 07:56:44 -0500 To: "Saverio Niccolini" X-Mailer: Apple Mail (2.753) Cc: rucus@ietf.org, Signaling TO Prevent SPIT Subject: Re: [Rucus] [spitstop] FYI - RUCUS mailing list is now live -pleasesubscribeso we can move SPIT conversation there X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0497301555==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============0497301555== Content-Type: multipart/alternative; boundary=Apple-Mail-19--712778748 --Apple-Mail-19--712778748 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Saverio, I share your view. Subscribers to SPITSTOP definitely now have the =20 word that the RUCUS list is starting up and so if they *choose* to =20 join the RUCUS list that is their choice. I don't think we should do =20 a mass subscription. As to moving the discussion over to RUCUS vs SPITSTOP, I do share =20 your concern about the wisdom of moving the the conversation 4 weeks =20 before the IETF, but I still think we *should* do it. I guess in my mind SPITSTOP was created to support a BOF proposal and =20= discussion for an earlier IETF. Now, RUCUS has been officially =20 sanctioned (as a BOF) to move forward and given an IETF mailing =20 list. We should make use of that "official" status to bring the =20 various SPIT discussions more tightly into the IETF web =20 infrastructure. As an IETF.org mailing list, it can be now found =20 among the list of IETF mailing lists. It also gives a chance for people who are on SPITSTOP to confirm that =20= they are *still* interested in working on the subject. Some of the =20 folks who may have signed up earlier may no longer be interested and =20 may simply not have unsubscribed. This gives a fresh chance to start =20= with people who are *definitely* interested in moving our work forward. As to numbers, we already have 16 people on the list (many of the =20 usual characters) and it was only announced a hour or two ago. My 2 cents, Dan On Feb 15, 2008, at 7:40 AM, Saverio Niccolini wrote: > Not sure all the people wants that, as admin of SPITSTOP > I am not feeling allowed to decide for people... > > Saverio > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division=09 > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > > >> -----Original Message----- >> From: spitstop-bounces@listserv.netlab.nec.de >> [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of >> Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Friday, February 15, 2008 1:38 PM >> To: Signaling TO Prevent SPIT >> Cc: rucus@ietf.org >> Subject: Re: [spitstop] FYI - RUCUS mailing list is now live >> -pleasesubscribeso we can move SPIT conversation there >> >> Let us do a batch registration of the folks subscribed to the >> SPITSTOP mailing list to the RUCUS mailing list. >> >> Dan could do that since he has the admin passwd. >> You, Saverio, need to send him the mail addresses. >> >> Ciao >> Hannes >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: spitstop-bounces@listserv.netlab.nec.de >>> [mailto:spitstop-bounces@listserv.netlab.nec.de] Im Auftrag von ext >>> Saverio Niccolini >>> Gesendet: Freitag, 15. Februar 2008 14:34 >>> An: Signaling TO Prevent SPIT >>> Cc: rucus@ietf.org >>> Betreff: Re: [spitstop] FYI - RUCUS mailing list is now live >>> - pleasesubscribeso we can move SPIT conversation there >>> >>> Dan, >>> >>> it is fine to move discussion over RUCUS but as I said, >> SPITSTOP has >>> now about 100 people registered, does it makes sense to move now (3 >>> weeks before IETF 71)? >>> It doesnot help if we have discussion on RUCUS among 5 >> people because >>> all the others still need to register (and it takes time...) >>> >>> Having said that, I have put RUCUS mailing list in CC to >> start it over >>> there as well... >>> >>> Saverio >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Dr. Saverio Niccolini >>> Senior Researcher >>> NEC Laboratories Europe, Network Research Division=09 >>> Kurfuerstenanlage 36, D-69115 Heidelberg >>> Tel. +49 (0)6221 4342-118 >>> Fax: +49 (0)6221 4342-155 >>> e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, >>> London W3 6BL Registered in England 2832014 >>> >>> >>> >>>> -----Original Message----- >>>> From: spitstop-bounces@listserv.netlab.nec.de >>>> [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf >>> Of Dan York >>>> Sent: Friday, February 15, 2008 11:43 AM >>>> To: Signaling TO Prevent SPIT; SIPPING LIST >>>> Subject: [spitstop] FYI - RUCUS mailing list is now live - please >>>> subscribeso we can move SPIT conversation there >>>> >>>> SIPPING and SPITSTOP members, >>>> >>>> FYI, the RUCUS mailing list is now live at: >>>> >>>> http://www.ietf.org/mailman/listinfo/rucus >>>> >>>> Please join that mailing list so that we can plan for the >> upcoming >>>> BOF in Philadelphia. >>>> >>>> Thanks, >>>> Dan >>>> >>>> P.S. If you aren't familiar with the RUCUS BoF, here is >> the approved >>>> request: http://www.tschofenig.priv.at/bof-rucus.html >>>> This is "Reducing Unwanted Communication Using SIP" and >> is designed >>>> to look at architectural issues involved with preventing >> voice spam, >>>> aka Spam for Internet Telephony aka SPIT. >>>> >>>> >>>> On Feb 14, 2008, at 10:57 AM, Dan York wrote: >>>> >>>> >>>> >>>> On Feb 12, 2008, at 11:25 PM, Saverio Niccolini wrote: >>>> >>>> >>>> -- as Cullen suggested, until the RUCUS mailing >> list is up and >>>> running, >>>> please use SPITSTOP mailing list for >> discussions related to this >>>> (avoid cross posting as I just did) >>>> >>>> >>>> On this point, I'll just mention that the RUCUS mailing >>>> list was requested back when Cullen sent out his note but >>>> seems to be hung up in the Secretariat transition and we are >>>> still waiting for the list to be created. >>>> >>>> Regards, >>>> Dan >>>> >>>> >>>> >>>> -- >>>> Dan York, CISSP, Director of Emerging Communication Technology >>>> Office of the CTO Voxeo Corporation dyork@voxeo.com >>>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>>> >>>> Bring your web applications to the phone. >>>> Find out how at http://evolution.voxeo.com >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> spitstop mailing list >>> spitstop@listserv.netlab.nec.de >>> https://listserv.netlab.nec.de/mailman/listinfo/spitstop >>> >> _______________________________________________ >> spitstop mailing list >> spitstop@listserv.netlab.nec.de >> https://listserv.netlab.nec.de/mailman/listinfo/spitstop >> > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus --=20 Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-19--712778748 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Saverio,

I share = your view. =A0Subscribers to SPITSTOP definitely now have the word that = the RUCUS list is starting up and so if they *choose* to join the RUCUS = list that is their choice. I don't think we should do a mass = subscription.

As to moving the = discussion over to RUCUS vs SPITSTOP, I do share your concern about the = wisdom of moving the the conversation 4 weeks before the IETF, but I = still think we *should* do it.

I guess in my mind = SPITSTOP was created to support a BOF proposal and discussion for an = earlier IETF. =A0Now, RUCUS has been officially sanctioned (as a BOF) to = move forward and given an IETF mailing list. =A0We should make use of = that "official" status to bring the various SPIT discussions more = tightly into the IETF web infrastructure. As an IETF.org mailing list, = it can be now found among the list of IETF mailing lists.

It also gives a chance for = people who are on SPITSTOP to confirm that they are *still* interested = in working on the subject. =A0Some of the folks who may have signed up = earlier may no longer be interested and may simply not have = unsubscribed. =A0This gives a fresh chance to start with people who are = *definitely* interested in moving our work forward.

As to numbers, we already = have 16 people on the list (many of the usual characters) and it was = only announced a hour or two ago.=A0

My 2 = cents,
Dan


On Feb 15, = 2008, at 7:40 AM, Saverio Niccolini wrote:

Not sure all the people wants that, as admin of = SPITSTOP
I am not feeling allowed to = decide for people...
Saverio

Dr. Saverio = Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research = Division =
Kurfuerstenanlage 36, D-69115 = Heidelberg
Tel. =A0 =A0 +49 (0)6221 = 4342-118
Fax: =A0 =A0 +49 (0)6221 = 4342-155
e-mail:=A0 saverio.niccolini@nw.neclab= .eu <-- !!! NEW ADDRESS !!!
NEC Europe = Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England = 2832014



-----Original Message-----
Sent: = Friday, February 15, 2008 1:38 PM
To: Signaling = TO Prevent SPIT
Subject: Re: [spitstop] FYI - RUCUS mailing list is = now live=A0
-pleasesubscribeso we can move SPIT conversation = there

Let us do a batch registration of the folks = subscribed to the=A0
SPITSTOP mailing list to the RUCUS mailing = list.=A0

Dan = could do that since he has the admin passwd.=A0
You, = Saverio, need to send him the mail addresses.=A0

Hannes


-----Urspr=FCngliche Nachricht-----
Saverio = Niccolini
Gesendet: Freitag, 15. Februar = 2008 14:34
An: Signaling TO Prevent = SPIT
Betreff: Re: [spitstop] FYI - RUCUS mailing list is = now live
- pleasesubscribeso we can move = SPIT conversation there

Dan,

it is = fine to move discussion over RUCUS but as I said,=A0
SPITSTOP has=A0
now about 100 people registered, = does it makes sense to move now (3=A0
weeks = before IETF 71)?
It doesnot help if we have = discussion on RUCUS among 5=A0
people because=A0
all the others still need to = register (and it takes time...)

Having said that, I have put = RUCUS mailing list in CC to=A0
start it over=A0
there as well...



Dr. Saverio = Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research = Division =
Kurfuerstenanlage 36, D-69115 = Heidelberg
Tel. =A0 =A0 +49 (0)6221 = 4342-118
Fax: =A0 =A0 +49 (0)6221 = 4342-155
e-mail:=A0 saverio.niccolini@nw.neclab= .eu <-- !!! NEW ADDRESS !!!
NEC Europe = Limited Registered Office: NEC House, 1 Victoria Road,=A0
London = W3 6BL Registered in England 2832014



-----Original = Message-----
Of Dan York
Sent: Friday, February 15, 2008 11:43 AM
To: Signaling TO Prevent SPIT; SIPPING = LIST
Subject: [spitstop] FYI - RUCUS = mailing list is now live - please=A0

SIPPING = and SPITSTOP members,
FYI, the RUCUS mailing list is = now live at:


Please join that mailing list so = that we can plan for the=A0
=
upcoming=A0
BOF in = Philadelphia.

Thanks,
Dan

P.S. If = you aren't familiar with the RUCUS BoF, here is=A0
=
the approved=A0
This is "Reducing Unwanted = Communication Using SIP" and=A0
=
is designed=A0
to look at = architectural issues involved with preventing=A0
=
voice spam,=A0
aka Spam for = Internet Telephony aka SPIT.


On Feb 14, 2008, at 10:57 AM, Dan York = wrote:



On Feb = 12, 2008, at 11:25 PM, Saverio Niccolini wrote:


-- as = Cullen suggested, until the RUCUS mailing=A0
=
list is up and=A0
please use SPITSTOP mailing list = for=A0
=
discussions related to = this
(avoid cross posting as I just = did)


On this = point, I'll just mention that the RUCUS mailing=A0
list was = requested back when Cullen sent out his note but=A0
seems to = be hung up in the Secretariat transition and we are=A0
still = waiting for the list to be created.

Regards,
Dan



--
Dan York, CISSP, Director = of Emerging Communication Technology
Office of the = CTO=A0 =A0 Voxeo = Corporation =A0 =A0 dyork@voxeo.com
Phone: +1-407-455-5859=A0 Skype: danyork=A0 http://www.voxeo.com

Bring your web applications to the phone.





spitstop mailing list

spitstop mailing list

Rucus mailing list

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=
= --Apple-Mail-19--712778748-- --===============0497301555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============0497301555==-- From rucus-bounces@ietf.org Fri Feb 15 06:35:07 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F9B3A6ACA; Fri, 15 Feb 2008 06:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yfAPHLfMEIo; Fri, 15 Feb 2008 06:35:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3648A3A695E; Fri, 15 Feb 2008 06:35:05 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C050A3A6AE3 for ; Fri, 15 Feb 2008 06:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrQXOjM102bt for ; Fri, 15 Feb 2008 06:35:04 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 003F93A695E for ; Fri, 15 Feb 2008 06:33:53 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 822E54C3B4; Fri, 15 Feb 2008 15:35:13 +0100 (CET) Date: Fri, 15 Feb 2008 15:35:13 +0100 From: Otmar Lendl To: spitstop@listserv.netlab.nec.de, rucus@ietf.org Message-ID: <20080215143513.GA13520@bofh.priv.at> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: [Rucus] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org As my mails to the sipping WG list exceeded Saverio's attention-span, I'll repost the main questions I raised here (spitstop & rucus) in short mails. Q1: In my opinion, the requirements for anti-SPIT technology depend a lot on the environment in and the application for which SIP is used. The most fundamental question is: a) Do we envision this technology to be part of a first line service? or, b) will the SIP service be a "second line service" which will exist in addition, but not as a replacement, for the current PSTN service? ------------------ Examples (not restricted to SIP) * Skype is b). SkypeIn/Out never succeeded in a). * Vonage is a) * Triple-Plays by cable operators are of type a) * Google-Talk is b) * FWD is b) * IM networks are b) ----------------- Why is this important? b) is a lot easier. You can assume fancier user interfaces and user will be willing to accept new types of interactions (e.g. buddy-list requests). a) has established communication procedures and expectations in a large user-base, plus often hard core requirements regarding call-blocking. Thus the solutions which can be workable for b) might not be suitable for a). Any discussion regarding the merit of protocol features needs to reflect the intended deployment scenarions. /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 07:15:00 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8643228D1DA; Fri, 15 Feb 2008 07:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.063 X-Spam-Level: X-Spam-Status: No, score=-0.063 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5pL5dLiklVs; Fri, 15 Feb 2008 07:14:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB9128D1B9; Fri, 15 Feb 2008 07:14:55 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B55D28D1A0 for ; Fri, 15 Feb 2008 07:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If-gEH+KAGsE for ; Fri, 15 Feb 2008 07:14:48 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C811528D1DE for ; Fri, 15 Feb 2008 07:14:39 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id B9B982C00C336; Fri, 15 Feb 2008 16:15:59 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUwmR1FHbBk5; Fri, 15 Feb 2008 16:15:59 +0100 (CET) Received: by smtp0.neclab.eu (Postfix, from userid 1001) id 984AD2C01D51A; Fri, 15 Feb 2008 16:15:59 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id BF5022C00C336; Fri, 15 Feb 2008 16:15:43 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 15 Feb 2008 16:15:43 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0EC9@mx1.office> In-Reply-To: <5A3C0727-0BDB-447E-97BC-1FCD874ECC57@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] [spitstop] FYI - RUCUS mailing list is now live-pleasesubscribeso we can move SPIT conversation there Thread-Index: Achv0kW6Gj3mgyxORUGgae1cfc7e7AAE0M8g References: DEFANGED[88]:DEFANGED[1314]:DEFANGED[6209]:DEFANGED[1]:<20080130165615.GA2033@nic.at><47A2C56E.2030909@gmx.net><20080209221108.GA11031@nic.at><47AF6103.7070803@cisco.com><20080211121826.GA13635@nic.at><5F6519B " " F2DE0404D99B7C7 " " 5607FF76FF4D0C0" " 5@mx1.office " DEFANGED[88]:"><08A7BA4E-07D3-4FCA-9569-4A3C4C8C5C26@voxeo.com><791986B7-17E1-4C4E-8B74-D61BA2138D2F@voxeo.com><5F6519BF2DE0404D99B7C75607FF76FF4D0E8C@mx1.office><5FB585F183235B42A9E70095055136FB79823E@DEMUEXC " " 012.nsn-intra.net><5F6519BF2DE0404D99B7C75607FF76FF4D0E94@mx1.office> <5A3C0727-0BDB-447E-97BC-1FCD874ECC57@voxeo.com> From: "Saverio Niccolini" To: "Dan York" X-Sanitizer: This message has been sanitized! MIME-Version: 1.0 Cc: rucus@ietf.org, Signaling TO Prevent SPIT Subject: Re: [Rucus] [spitstop] FYI - RUCUS mailing list is now live-pleasesubscribeso we can move SPIT conversation there X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dan, ok then, let's move to RUCUS for the discussions related to this BoF but not copy and paste all the subscribers. Saverio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division = Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 = = > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] = > On Behalf Of Dan York > Sent: Friday, February 15, 2008 1:57 PM > To: Saverio Niccolini > Cc: rucus@ietf.org; Signaling TO Prevent SPIT > Subject: Re: [Rucus] [spitstop] FYI - RUCUS mailing list is = > now live-pleasesubscribeso we can move SPIT conversation there > = > Saverio, > = > I share your view. Subscribers to SPITSTOP definitely now = > have the word that the RUCUS list is starting up and so if = > they *choose* to join the RUCUS list that is their choice. I = > don't think we should do a mass subscription. > = > As to moving the discussion over to RUCUS vs SPITSTOP, I do = > share your concern about the wisdom of moving the the = > conversation 4 weeks before the IETF, but I still think we = > *should* do it. > = > I guess in my mind SPITSTOP was created to support a BOF = > proposal and discussion for an earlier IETF. Now, RUCUS has = > been officially sanctioned (as a BOF) to move forward and = > given an IETF mailing list. We should make use of that = > "official" status to bring the various SPIT discussions more = > tightly into the IETF web infrastructure. As an IETF.org = > mailing list, it can be now found among the list of IETF = > mailing lists. > = > It also gives a chance for people who are on SPITSTOP to = > confirm that they are *still* interested in working on the = > subject. Some of the folks who may have signed up earlier = > may no longer be interested and may simply not have = > unsubscribed. This gives a fresh chance to start with people = > who are *definitely* interested in moving our work forward. > = > As to numbers, we already have 16 people on the list (many of = > the usual characters) and it was only announced a hour or two ago. = > = > My 2 cents, > Dan > = > = > On Feb 15, 2008, at 7:40 AM, Saverio Niccolini wrote: > = > = > Not sure all the people wants that, as admin of SPITSTOP > I am not feeling allowed to decide for people... > = > Saverio > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division = > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > = > = > = > = > -----Original Message----- > From: spitstop-bounces@listserv.netlab.nec.de = > = > [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of = > Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Friday, February 15, 2008 1:38 PM > To: Signaling TO Prevent SPIT > Cc: rucus@ietf.org > Subject: Re: [spitstop] FYI - RUCUS mailing = > list is now live = > -pleasesubscribeso we can move SPIT conversation there > = > Let us do a batch registration of the folks = > subscribed to the = > SPITSTOP mailing list to the RUCUS mailing list. = > = > Dan could do that since he has the admin passwd. = > You, Saverio, need to send him the mail addresses. = > = > Ciao > Hannes > = > = > = > -----Urspr=FCngliche Nachricht----- > Von: spitstop-bounces@listserv.netlab.nec.de > = > [mailto:spitstop-bounces@listserv.netlab.nec.de] Im Auftrag von ext = > Saverio Niccolini > Gesendet: Freitag, 15. Februar 2008 14:34 > An: Signaling TO Prevent SPIT > Cc: rucus@ietf.org > Betreff: Re: [spitstop] FYI - RUCUS = > mailing list is now live > - pleasesubscribeso we can move SPIT = > conversation there > = > Dan, > = > it is fine to move discussion over = > RUCUS but as I said, = > = > SPITSTOP has = > = > now about 100 people registered, does = > it makes sense to move now (3 = > weeks before IETF 71)? > It doesnot help if we have discussion = > on RUCUS among 5 = > = > people because = > = > all the others still need to register = > (and it takes time...) > = > Having said that, I have put RUCUS = > mailing list in CC to = > = > start it over = > = > there as well... > = > Saverio > = > = > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network = > Research Division = > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu = > <-- !!! NEW ADDRESS !!! > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC Europe Limited Registered Office: = > NEC House, 1 Victoria Road, = > London W3 6BL Registered in England 2832014 > = > = > = > = > -----Original Message----- > From: = > spitstop-bounces@listserv.netlab.nec.de > = > [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf > = > Of Dan York > = > Sent: Friday, February 15, 2008 11:43 AM > To: Signaling TO Prevent SPIT; = > SIPPING LIST > Subject: [spitstop] FYI - RUCUS = > mailing list is now live - please = > subscribeso we can move SPIT = > conversation there > = > SIPPING and SPITSTOP members, > = > FYI, the RUCUS mailing list is = > now live at: > = > = > http://www.ietf.org/mailman/listinfo/rucus > = > Please join that mailing list = > so that we can plan for the = > = > upcoming = > = > BOF in Philadelphia. > = > Thanks, > Dan > = > P.S. If you aren't familiar = > with the RUCUS BoF, here is = > = > the approved = > = > request: = > http://www.tschofenig.priv.at/bof-rucus.html > This is "Reducing Unwanted = > Communication Using SIP" and = > = > is designed = > = > to look at architectural issues = > involved with preventing = > = > voice spam, = > = > aka Spam for Internet Telephony = > aka SPIT. > = > = > On Feb 14, 2008, at 10:57 AM, = > Dan York wrote: > = > = > = > On Feb 12, 2008, at 11:25 PM, = > Saverio Niccolini wrote: > = > = > -- as Cullen suggested, until = > the RUCUS mailing = > = > list is up and = > = > running, > please use SPITSTOP mailing list for = > = > discussions related to this > = > (avoid cross posting as I just did) > = > = > On this point, I'll just = > mention that the RUCUS mailing = > list was requested back when = > Cullen sent out his note but = > seems to be hung up in the = > Secretariat transition and we are = > still waiting for the list to = > be created. > = > Regards, > Dan > = > = > = > -- > Dan York, CISSP, Director of = > Emerging Communication Technology > Office of the CTO Voxeo = > Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: = > danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com = > http://www.disruptivetelephony.com > = > Bring your web applications to = > the phone. > Find out how at = > http://evolution.voxeo.com > = > = > = > = > = > = > _______________________________________________ > spitstop mailing list > spitstop@listserv.netlab.nec.de > = > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > = > = > _______________________________________________ > spitstop mailing list > spitstop@listserv.netlab.nec.de > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > = > = > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > = > = > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > = > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > = > = > = > = > = _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 07:23:11 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C6D28D20F; Fri, 15 Feb 2008 07:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUwEshO3n8K0; Fri, 15 Feb 2008 07:23:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52A93A6AF6; Fri, 15 Feb 2008 07:23:09 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF413A6AF6 for ; Fri, 15 Feb 2008 07:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpbsnqKkAtah for ; Fri, 15 Feb 2008 07:23:07 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 56F1E3A67DB for ; Fri, 15 Feb 2008 07:23:07 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D22362C01D460 for ; Fri, 15 Feb 2008 16:24:27 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0Sm9+smfTVm for ; Fri, 15 Feb 2008 16:24:27 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id C1B5C2C00C336 for ; Fri, 15 Feb 2008 16:24:22 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 16:24:22 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0ECC@mx1.office> In-Reply-To: <20080215143513.GA13520@bofh.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] Context for rucus Thread-Index: Achv4Ax17nhtLgxESKG1skRdTdgYdAABcUmQ References: <20080215143513.GA13520@bofh.priv.at> From: "Saverio Niccolini" To: Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Otmar, > Q1: > > In my opinion, the requirements for anti-SPIT technology > depend a lot on > the environment in and the application for which SIP is used. The most > fundamental question is: > > a) Do we envision this technology to be part of a first line service? > > or, > > b) will the SIP service be a "second line service" which will exist > in addition, but not as a replacement, for the current PSTN service? Very good question, now I got what you wanted to say, thanks :-) Answer to Q1: I would like to have solutions for b) in a first place to explore the field, restrictions of the solution that will be working for a) can be worked out later. I would then focus for b) in RUCUS. Since you raised the point. Q1a: What about restricting the RUCUS use cases to: -- single administrative domain -- if multiple domains are considered then assume a peering/trust agreement between them (secure bi-lateral connections among them) This would also help in confining the topic. Cheers, Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 08:13:15 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0232928D2CC; Fri, 15 Feb 2008 08:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOVKFpZwf5lb; Fri, 15 Feb 2008 08:13:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A79428D2D4; Fri, 15 Feb 2008 08:09:03 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72AEB3A68E7 for ; Fri, 15 Feb 2008 08:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyqPoqZFH2kJ for ; Fri, 15 Feb 2008 08:01:25 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id E530128D242 for ; Fri, 15 Feb 2008 07:59:35 -0800 (PST) Received: by mail.iptel.org (Postfix, from userid 103) id E25D81811DB8; Fri, 15 Feb 2008 17:00:55 +0100 (CET) Received: from [10.36.2.34] (unknown [217.9.54.26]) by mail.iptel.org (Postfix) with ESMTP id C26D81810C14 for ; Fri, 15 Feb 2008 17:00:52 +0100 (CET) Message-ID: <47B5B733.1030607@tekelec.com> Date: Fri, 15 Feb 2008 17:00:51 +0100 From: Dorgham Sisalem User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: rucus@ietf.org References: <20080215143513.GA13520@bofh.priv.at> <5F6519BF2DE0404D99B7C75607FF76FF4D0ECC@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0ECC@mx1.office> X-Mailman-Approved-At: Fri, 15 Feb 2008 08:09:03 -0800 Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org I very much agree with Otmar that the requirements and possible solutions for first and second lines are different. But I am not sure that spammers will make this distinction. Actually SPIT is a lot more annoying to users with a first-line VoIP service so leaving them out would not be helpful. A general framework should therefore address both scenarios. Restricting the environment -only trusted relations or one administrative domain- might actually be a good starting point as there is still no real peering between VoIP providers and as long as peering is done over PSTN, there will still be some -hopefully prohibiting- costs for large SPIT actions. cheers Saverio Niccolini wrote: > Hi Otmar, > > >> Q1: >> >> In my opinion, the requirements for anti-SPIT technology >> depend a lot on >> the environment in and the application for which SIP is used. The most >> fundamental question is: >> >> a) Do we envision this technology to be part of a first line service? >> >> or, >> >> b) will the SIP service be a "second line service" which will exist >> in addition, but not as a replacement, for the current PSTN service? >> > > Very good question, now I got what you wanted to say, thanks :-) > > Answer to Q1: > I would like to have solutions for b) in a first place to explore the field, > restrictions of the solution that will be working for a) can be worked out > later. > > I would then focus for b) in RUCUS. > > Since you raised the point. > > Q1a: > What about restricting the RUCUS use cases to: > -- single administrative domain > -- if multiple domains are considered then assume a peering/trust agreement > between them (secure bi-lateral connections among them) > > This would also help in confining the topic. > > Cheers, > Saverio > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 08:13:27 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95BB128D2C8; Fri, 15 Feb 2008 08:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDrwaIrySdi2; Fri, 15 Feb 2008 08:13:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F0528D2D9; Fri, 15 Feb 2008 08:13:18 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713DF28D2CE for ; Fri, 15 Feb 2008 08:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAspj-+lEDzD for ; Fri, 15 Feb 2008 08:13:15 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 0831D28D2DF for ; Fri, 15 Feb 2008 08:09:25 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 6F4274C3B4; Fri, 15 Feb 2008 17:10:45 +0100 (CET) Date: Fri, 15 Feb 2008 17:10:45 +0100 From: Otmar Lendl To: Saverio Niccolini , spitstop@listserv.netlab.nec.de Message-ID: <20080215161045.GC13520@bofh.priv.at> References: <20080215143513.GA13520@bofh.priv.at> <5F6519BF2DE0404D99B7C75607FF76FF4D0ECC@mx1.office> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0ECC@mx1.office> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: rucus@ietf.org Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org [I'm keeping spitstop Cc'd for the moment] On 2008/02/15 16:02, Saverio Niccolini wrote: > > Q1: > > > > In my opinion, the requirements for anti-SPIT technology > > depend a lot on > > the environment in and the application for which SIP is used. The most > > fundamental question is: > > > > a) Do we envision this technology to be part of a first line service? > > > > or, > > > > b) will the SIP service be a "second line service" which will exist > > in addition, but not as a replacement, for the current PSTN service? > > Very good question, now I got what you wanted to say, thanks :-) Good, then I'm looking forward to your answers on sipping as well. > Answer to Q1: > I would like to have solutions for b) in a first place to explore the field, > restrictions of the solution that will be working for a) can be worked out > later. No. Most of them can't. > I would then focus for b) in RUCUS. > > Since you raised the point. > > Q1a: > What about restricting the RUCUS use cases to: > -- single administrative domain > -- if multiple domains are considered then assume a peering/trust agreement > between them (secure bi-lateral connections among them) > > This would also help in confining the topic. Sorry, but if you're restricting the discussions to case b) and just internal or communication between trusted parties (without transit), then the focus is so narrow that I don't see a point in doing any work on this. In the "single administrative domain" case you don't write fancy "this call is probably spit"-header into the signalling if you detect spit, but instead you disable the account of the offender. In the pure bi-lateral trusted case you do the same. If you know that this is a likely spit-call, then don't even pass it to your peer. Such settings don't need protocol solutions, they need passive monitoring plus good old-fashioned abuse-handling. That's no topic for the IETF. /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 08:13:32 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874D73A6AF0; Fri, 15 Feb 2008 08:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.007 X-Spam-Level: X-Spam-Status: No, score=-0.007 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMtrtPJo5Lmd; Fri, 15 Feb 2008 08:13:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D7A3A688B; Fri, 15 Feb 2008 08:13:24 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF1628D2FF for ; Fri, 15 Feb 2008 08:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsjOR2-nChn4 for ; Fri, 15 Feb 2008 08:13:20 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 2CD7928D2F6 for ; Fri, 15 Feb 2008 08:11:00 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 27995859 for rucus@ietf.org; Fri, 15 Feb 2008 16:12:19 +0000 Mime-Version: 1.0 (Apple Message framework v753) To: rucus@ietf.org Message-Id: <3FEC61B4-999F-4A99-926F-F0FD8FC06196@voxeo.com> From: Dan York Date: Fri, 15 Feb 2008 11:12:18 -0500 X-Mailer: Apple Mail (2.753) Subject: [Rucus] FYI - RUCUS mail archive currently broken... X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2017211818==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============2017211818== Content-Type: multipart/alternative; boundary=Apple-Mail-44--701044561 --Apple-Mail-44--701044561 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI, while the RUCUS list is up and running, the archive is currently broken: http://www.ietf.org/mail-archive/web/rucus/ I filed a report with IETF-action this morning. Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-44--701044561 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI, while the RUCUS list is up and running, the archive is currently = broken:


I filed a report with = IETF-action this morning.

Dan

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-44--701044561-- --===============2017211818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============2017211818==-- From rucus-bounces@ietf.org Fri Feb 15 10:50:41 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4517228D2CF; Fri, 15 Feb 2008 10:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=-2.099, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5LbGiAcoL4u; Fri, 15 Feb 2008 10:50:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D4B3A6B38; Fri, 15 Feb 2008 10:50:40 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F433A6B18 for ; Fri, 15 Feb 2008 10:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq3bkA6Clywq for ; Fri, 15 Feb 2008 10:37:00 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5E0CE3A695F for ; Fri, 15 Feb 2008 10:37:00 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2008 10:38:21 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1FIcLS7023461; Fri, 15 Feb 2008 10:38:21 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1FIcJvn010609; Fri, 15 Feb 2008 18:38:19 GMT From: "Dan Wing" To: "'Signaling TO Prevent SPIT'" References: DEFANGED[6209]:DEFANGED[1]:<20080130165615.GA2033@nic.at><47A2C56E.2030909@gmx.net><20080209221108.GA11031@nic.at><47AF6103.7070803@cisco.com><20080211121826.GA13635@nic.at><5F6519BF2DE0404D99B7C75607FF76FF4D0C0" " 5@mx1.office " "><08A7BA4E-07D3-4FCA-9569-4A3C4C8C5C26@voxeo.com><791986B7-17E1-4C4E-8B74-D61BA2138D2F@voxeo.com><5F6519BF2DE0404D99B7C75607FF76FF4D0E8C@mx1.office><5FB585F183235B42A9E70095055136FB79823E@DEMUEXC012.nsn-intra.net> <5F6519BF2DE0404D99B7C75607FF76FF4D0E94@mx1.office> Date: Fri, 15 Feb 2008 10:38:20 -0800 Message-ID: <122601c87001$f0a34810$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Achvv5PsJYJAmn0BTAS2RfRsUEkJ5wADynWwAAAwEVAAABaFUAAMfVPg In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0E94@mx1.office> Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Mailman-Approved-At: Fri, 15 Feb 2008 10:50:39 -0800 Cc: rucus@ietf.org Subject: Re: [Rucus] [spitstop] FYI - RUCUS mailing list is now live-pleasesubscribeso we can move SPIT conversation there X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > Not sure all the people wants that, as admin of SPITSTOP > I am not feeling allowed to decide for people... Dan York can have mailman 'invite' the users to subscribe, which requires each person to click on a link (or reply to an email, as they prefer) for their subscription to RUCUS to become active. -d _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 10:50:41 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E8928D0F4; Fri, 15 Feb 2008 10:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=-2.044, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYpq-RwnzBOh; Fri, 15 Feb 2008 10:50:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE69E28D258; Fri, 15 Feb 2008 10:50:40 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CF6C28CF7F for ; Fri, 15 Feb 2008 10:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DT7woThwz2X for ; Fri, 15 Feb 2008 10:37:57 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E08863A6B45 for ; Fri, 15 Feb 2008 10:37:57 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 15 Feb 2008 10:39:20 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1FIdIVL023686; Fri, 15 Feb 2008 10:39:18 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1FIdHJg007398; Fri, 15 Feb 2008 18:39:17 GMT From: "Dan Wing" To: "'Signaling TO Prevent SPIT'" , "'Saverio Niccolini'" References: DEFANGED[6209]:DEFANGED[1]:<20080130165615.GA2033@nic.at><47A2C56E.2030909@gmx.net><20080209221108.GA11031@nic.at><47AF6103.7070803@cisco.com><20080211121826.GA13635@nic.at><5F6519BF2DE0404D99B7C75607FF76FF4D0C0" " 5@mx1.office " "><08A7BA4E-07D3-4FCA-9569-4A3C4C8C5C26@voxeo.com><791986B7-17E1-4C4E-8B74-D61BA2138D2F@voxeo.com><5F6519BF2DE0404D99B7C75607FF76FF4D0E8C@mx1.office><5FB585F183235B42A9E70095055136FB79823E@DEMUEXC012.nsn-intra.net><5F6519BF2DE0404D99B7C75607FF76FF4D0E94@mx1.office> <5A3C0727-0BDB-447E-97BC-1FCD874ECC57@voxeo.com> Date: Fri, 15 Feb 2008 10:39:18 -0800 Message-ID: <122701c87002$130d8dc0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Achv0kh8YbjpoQqaTrywl2jlpgZNAwAL7NAQ In-Reply-To: <5A3C0727-0BDB-447E-97BC-1FCD874ECC57@voxeo.com> Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Mailman-Approved-At: Fri, 15 Feb 2008 10:50:39 -0800 Cc: rucus@ietf.org Subject: Re: [Rucus] [spitstop] FYI - RUCUS mailing list is now live-pleasesubscribeso we can move SPIT conversation there X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > As to moving the discussion over to RUCUS vs SPITSTOP, I do > share your concern about the wisdom of moving the the > conversation 4 weeks before the IETF, but I still think we > *should* do it. Most important, it is useful to have mailing list archives on an IETF server when we are publicly discussing an IETF BoF. -d _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 10:51:12 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9AF13A6B97; Fri, 15 Feb 2008 10:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-2.223, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAtM5Fdlo49W; Fri, 15 Feb 2008 10:51:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169863A6B45; Fri, 15 Feb 2008 10:51:12 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1503A6B45 for ; Fri, 15 Feb 2008 10:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yKXC7yjJ7kk for ; Fri, 15 Feb 2008 10:51:10 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 821B53A6B18 for ; Fri, 15 Feb 2008 10:51:10 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Feb 2008 10:52:31 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1FIqUDK026263; Fri, 15 Feb 2008 10:52:30 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1FIqSvn023523; Fri, 15 Feb 2008 18:52:28 GMT From: "Dan Wing" To: References: <20080215143513.GA13520@bofh.priv.at><5F6519BF2DE0404D99B7C75607FF76FF4D0ECC@mx1.office> <20080215161045.GC13520@bofh.priv.at> Date: Fri, 15 Feb 2008 10:52:29 -0800 Message-ID: <124401c87003$ea9930e0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Achv7WRBGxCSivvKQVmbtIj+A802QAAFjxqQ In-Reply-To: <20080215161045.GC13520@bofh.priv.at> Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Signaling TO Prevent SPIT' Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > In the "single administrative domain" case you don't write fancy "this > call is probably spit"-header into the signalling if you detect spit, > but instead you disable the account of the offender. Existing email-based spam systems, such as most notably SpamAssassin, create exactly such a header, which the user is then able to filter at their mail user agent or using a filter in their mail storage server (using for example .procmailrc to filter). This provides the *user*, not the domain administrator, the power to ignore or automatically delete certain email. I expect a similar model makes sense for realtime communications. Do you believe a similar model makes no sense for realtime communications? -d > In the pure bi-lateral trusted case you do the same. If you know that > this is a likely spit-call, then don't even pass it to your peer. > > Such settings don't need protocol solutions, they need passive > monitoring plus good old-fashioned abuse-handling. > > That's no topic for the IETF. > > /ol > -- > -=- Otmar Lendl -- ol@bofh.priv.at -=- > _______________________________________________ > spitstop mailing list > spitstop@listserv.netlab.nec.de > https://listserv.netlab.nec.de/mailman/listinfo/spitstop _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 11:40:55 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5E33A6B98; Fri, 15 Feb 2008 11:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YzAsinVt+XW; Fri, 15 Feb 2008 11:40:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2274828D1DA; Fri, 15 Feb 2008 11:40:54 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD923A6B85 for ; Fri, 15 Feb 2008 11:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSrUJSSHzd5w for ; Fri, 15 Feb 2008 11:40:51 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id AD90528CF3C for ; Fri, 15 Feb 2008 11:39:31 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id E8E044C3CE; Fri, 15 Feb 2008 20:40:50 +0100 (CET) Date: Fri, 15 Feb 2008 20:40:50 +0100 From: Otmar Lendl To: Dan Wing Message-ID: <20080215194050.GD13520@bofh.priv.at> References: <20080215161045.GC13520@bofh.priv.at> <124401c87003$ea9930e0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <124401c87003$ea9930e0$c4f0200a@cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: rucus@ietf.org, 'Signaling TO Prevent SPIT' Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/15 19:02, Dan Wing wrote: > > In the "single administrative domain" case you don't write fancy "this > > call is probably spit"-header into the signalling if you detect spit, > > but instead you disable the account of the offender. > > Existing email-based spam systems, such as most notably SpamAssassin, > create exactly such a header, which the user is then able to filter > at their mail user agent or using a filter in their mail storage > server (using for example .procmailrc to filter). This provides > the *user*, not the domain administrator, the power to ignore or > automatically delete certain email. > > I expect a similar model makes sense for realtime communications. Do > you believe a similar model makes no sense for realtime communications? It makes sense in a multi-operator environment. It make little sense within a walled garden of a single operator. In the case of SPAM, no operator (expect perhaps the russian business network and a few other shady outfits) allows customers to spam. It's against their terms of service, and these are usually enforced. The problem with spam comes from the fact that e-mail crosses open administrative boundaries thus evading any accountability. Let's take a closer look at your SpamAssassin example: In the email case, the recipient's mail provider will tag messages as they come in. Your ISP has no recourse against the sender of the spam (other than blocking mail), there is no business relationship, no contract, no right to sue, no damages. Often enough, they don't even know the real-world identity of those who handed them the spam. If, as Saverio suggested, we look at the insular case, of just a single, unconnected operator then this changes: Tagging the incoming mail is equivalent to tagging outgoing email (remember, everything is internal). Whenever there is mail tagged as spam in this setup, the provider *knows* the account of the sender. It's one of his own customers. Hopefully a paying one, but at least someone with account credentials who agreed to some Terms&Conditions when signing up. So, whenever this provider is capable of telling his customer that this new mail is probably spam, he also knows which of his customers just sent this spam. As that's against the T&C, he can yank the account of the perpetrator and keep his network clean. In other words, within a single administrative domain, Spam/Spit is a policing issue, and not a protocol issue. Yes, the IETF is full of techies, but that doesn't mean that a new protocol is the best solution to every problem. Hammer & nails, you know the adage. (Along the same lines: Within a single domain, you don't need SIP Identity, the provider can authenticate customers and enforce valid From: headers.) /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 12:07:18 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C183A6B8B; Fri, 15 Feb 2008 12:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-1.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCLrBHRkH48d; Fri, 15 Feb 2008 12:07:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D6C3A6B97; Fri, 15 Feb 2008 12:07:14 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654AB3A6B97 for ; Fri, 15 Feb 2008 12:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDvvqCJHNS2h for ; Fri, 15 Feb 2008 12:07:12 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C53D93A6B8D for ; Fri, 15 Feb 2008 12:07:07 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Feb 2008 12:08:28 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1FK8Saf009950; Fri, 15 Feb 2008 12:08:28 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1FK8RJg029981; Fri, 15 Feb 2008 20:08:27 GMT From: "Dan Wing" To: "'Otmar Lendl'" References: <20080215161045.GC13520@bofh.priv.at> <124401c87003$ea9930e0$c4f0200a@cisco.com> <20080215194050.GD13520@bofh.priv.at> Date: Fri, 15 Feb 2008 12:08:27 -0800 Message-ID: <139b01c8700e$876e1250$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchwCrk/dxr+6kY5RhWHFmL5LOsrIgAAr6Jg In-Reply-To: <20080215194050.GD13520@bofh.priv.at> Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: rucus@ietf.org, 'Signaling TO Prevent SPIT' Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > -----Original Message----- > From: Otmar Lendl [mailto:ol@bofh.priv.at] > Sent: Friday, February 15, 2008 11:41 AM > To: Dan Wing > Cc: rucus@ietf.org; 'Signaling TO Prevent SPIT' > Subject: Re: [Rucus] [spitstop] Context for rucus > > On 2008/02/15 19:02, Dan Wing wrote: > > > In the "single administrative domain" case you don't > write fancy "this > > > call is probably spit"-header into the signalling if you > detect spit, > > > but instead you disable the account of the offender. > > > > Existing email-based spam systems, such as most notably > SpamAssassin, > > create exactly such a header, which the user is then able to filter > > at their mail user agent or using a filter in their mail storage > > server (using for example .procmailrc to filter). This provides > > the *user*, not the domain administrator, the power to ignore or > > automatically delete certain email. > > > > I expect a similar model makes sense for realtime > communications. Do > > you believe a similar model makes no sense for realtime > communications? > > It makes sense in a multi-operator environment. > > It make little sense within a walled garden of a single operator. Er, I don't follow. Let's take a specific recent example at my own house. My wife and I contribute to a variety of environmental non-profit organizations (e.g., World Wildlife Fund, Monterey Bay Aquarium). Occasionally they call the house to invite us to a special event or solicit special contributions for a specific cause. I imagine that some people who contribute to these same organizations receive similar phone calls. It is reasonable to expect that some number of those people would press the "SPAM" button on their phones, even though they have a previously-established business relationship with that non-profit organization. Let us assume the WWF, the Monterey Bay Aquarium, and my phone are all served by the same phone company. In my case with the PSTN, they all are. You are suggesting that if enough people complain that they were spammed by WWF or the Monterey Bay Aquarium, that the phone company would have some right, or some expectation, or some ability, to cut off the ability of that non-profit organization to initiate outgoing calls -- that is, to terminate their service. I do not believe that is possible, nor is it reasonable to expect, even within a single phone company. > In the case of SPAM, no operator (expect perhaps the russian business > network and a few other shady outfits) allows customers to spam. > It's against their terms of service, and these are usually enforced. > > The problem with spam comes from the fact that e-mail crosses > open administrative boundaries thus evading any accountability. > > Let's take a closer look at your SpamAssassin example: In the > email case, the recipient's mail provider will tag messages > as they come in. Your ISP has no recourse against the sender > of the spam (other than blocking mail), there is no business > relationship, no contract, no right to sue, no damages. Often > enough, they don't even know the real-world identity of those > who handed them the spam. > > If, as Saverio suggested, we look at the insular case, of > just a single, unconnected operator then this changes: > Tagging the incoming mail is equivalent to tagging outgoing > email (remember, everything is internal). Whenever there is mail > tagged as spam in this setup, the provider *knows* the account > of the sender. It's one of his own customers. Hopefully a paying > one, but at least someone with account credentials who agreed > to some Terms&Conditions when signing up. > > So, whenever this provider is capable of telling his customer > that this new mail is probably spam, he also knows which of > his customers just sent this spam. As that's against the T&C, > he can yank the account of the perpetrator and keep his network > clean. You're viewing spam as a binary operation: someone is spamming ("1"), and should be cut off from service; everyone else is not spamming ("0"), and can be allowed to continue as a paying customer. It is not nearly so clear cut. Wish it were. -d > In other words, within a single administrative domain, Spam/Spit > is a policing issue, and not a protocol issue. Yes, the IETF is > full of techies, but that doesn't mean that a new protocol is the > best solution to every problem. Hammer & nails, you know the adage. > > (Along the same lines: Within a single domain, you don't need > SIP Identity, > the provider can authenticate customers and enforce valid > From: headers.) > > /ol > -- > -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 13:46:16 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA3D28C3A5; Fri, 15 Feb 2008 13:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIsn3zFMDRAF; Fri, 15 Feb 2008 13:46:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7E23A69B1; Fri, 15 Feb 2008 13:46:15 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A5028C1E5 for ; Fri, 15 Feb 2008 13:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H79yqr-V8MaO for ; Fri, 15 Feb 2008 13:46:14 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 68DA53A685F for ; Fri, 15 Feb 2008 13:46:12 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 806174C3CE; Fri, 15 Feb 2008 22:47:31 +0100 (CET) Date: Fri, 15 Feb 2008 22:47:31 +0100 From: Otmar Lendl To: Dan Wing Message-ID: <20080215214731.GE13520@bofh.priv.at> References: <20080215161045.GC13520@bofh.priv.at> <124401c87003$ea9930e0$c4f0200a@cisco.com> <20080215194050.GD13520@bofh.priv.at> <139b01c8700e$876e1250$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <139b01c8700e$876e1250$c4f0200a@cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: rucus@ietf.org, 'Signaling TO Prevent SPIT' Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/15 21:02, Dan Wing wrote: > > > > > > I expect a similar model makes sense for realtime communications. > > > Do you believe a similar model makes no sense for realtime > > > communications? > > > > It makes sense in a multi-operator environment. > > > > It make little sense within a walled garden of a single operator. > > Er, I don't follow. > > Let's take a specific recent example at my own house. My wife > and I contribute to a variety of environmental non-profit > organizations (e.g., World Wildlife Fund, Monterey Bay > Aquarium). Occasionally they call the house to invite us > to a special event or solicit special contributions for a > specific cause. > > I imagine that some people who contribute to these same > organizations receive similar phone calls. It is reasonable to > expect that some number of those people would press the > "SPAM" button on their phones, even though they have a > previously-established business relationship with that > non-profit organization. > > Let us assume the WWF, the Monterey Bay Aquarium, and my > phone are all served by the same phone company. In my > case with the PSTN, they all are. > > You are suggesting that if enough people complain that they > were spammed by WWF or the Monterey Bay Aquarium, that the > phone company would have some right, or some expectation, > or some ability, to cut off the ability of that non-profit > organization to initiate outgoing calls -- that is, to > terminate their service. > > I do not believe that is possible, nor is it reasonable > to expect, even within a single phone company. I agree that turning off PSTN service is not a trivial option. That is exactly why my first question was: do we deal with a PSTN-replacement service or a second line (alternative communication) service? Your example is using the service expectations and legal framework of the PSTN. Saverio's answer was different: he wants to consider second line services first. I still contend that within those, different rules apply. E.g. if I send out too much messages within LinkedIn, Skype or some other Web 2.0 style communication platform, they will kick me off. If you attract too many complaints for your hotmail account, you're gone. I'm not sure about the US situation, but here in Austria the same legal framework which defines your rights and the carrier's duties with respect to PSTN service also describes what kind of conduct (e.g. telemarketing) is illegal and even tasks a government agency with acting on complaints from users. That does not apply to any fancy "Free World Dialup" knock-off that someone might try to establish here. So yes, I agree with your example (though I don't know what a fancy header would help), which actually bolsters my claim that we really need to be clear whether we're building a solution for PSTN replacement services or just for fancy alternative services. /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 15 14:00:38 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E7728C390; Fri, 15 Feb 2008 14:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFJVQ-9wrt7Z; Fri, 15 Feb 2008 14:00:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25CD73A6B4C; Fri, 15 Feb 2008 14:00:37 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7903A6B46 for ; Fri, 15 Feb 2008 14:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7Cee-DUD88P for ; Fri, 15 Feb 2008 14:00:34 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6B86B3A6AE0 for ; Fri, 15 Feb 2008 14:00:34 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2008 14:01:55 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1FM1qav006290; Fri, 15 Feb 2008 14:01:52 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1FM1pJg008246; Fri, 15 Feb 2008 22:01:52 GMT From: "Dan Wing" To: "'Otmar Lendl'" References: <20080215161045.GC13520@bofh.priv.at> <124401c87003$ea9930e0$c4f0200a@cisco.com> <20080215194050.GD13520@bofh.priv.at> <139b01c8700e$876e1250$c4f0200a@cisco.com> <20080215214731.GE13520@bofh.priv.at> Date: Fri, 15 Feb 2008 14:01:51 -0800 Message-ID: <01a101c8701e$5f2c07b0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080215214731.GE13520@bofh.priv.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchwHGQM3+fu/TZGR3uW36h+49/9AQAAQ9Gw Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: rucus@ietf.org, 'Signaling TO Prevent SPIT' Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > -----Original Message----- > From: Otmar Lendl [mailto:ol@bofh.priv.at] > Sent: Friday, February 15, 2008 1:48 PM > To: Dan Wing > Cc: rucus@ietf.org; 'Signaling TO Prevent SPIT' > Subject: Re: [Rucus] [spitstop] Context for rucus > > On 2008/02/15 21:02, Dan Wing wrote: > > > > > > > > I expect a similar model makes sense for realtime > communications. > > > > Do you believe a similar model makes no sense for realtime > > > > communications? > > > > > > It makes sense in a multi-operator environment. > > > > > > It make little sense within a walled garden of a single operator. > > > > Er, I don't follow. > > > > > > Let's take a specific recent example at my own house. My wife > > and I contribute to a variety of environmental non-profit > > organizations (e.g., World Wildlife Fund, Monterey Bay > > Aquarium). Occasionally they call the house to invite us > > to a special event or solicit special contributions for a > > specific cause. > > > > I imagine that some people who contribute to these same > > organizations receive similar phone calls. It is reasonable to > > expect that some number of those people would press the > > "SPAM" button on their phones, even though they have a > > previously-established business relationship with that > > non-profit organization. > > > > Let us assume the WWF, the Monterey Bay Aquarium, and my > > phone are all served by the same phone company. In my > > case with the PSTN, they all are. > > > > You are suggesting that if enough people complain that they > > were spammed by WWF or the Monterey Bay Aquarium, that the > > phone company would have some right, or some expectation, > > or some ability, to cut off the ability of that non-profit > > organization to initiate outgoing calls -- that is, to > > terminate their service. > > > > I do not believe that is possible, nor is it reasonable > > to expect, even within a single phone company. > > I agree that turning off PSTN service is not a trivial option. Neither would turning off email -- imagine this is a newsletter, distributed via email, from those same non-profit organizations. > That is exactly why my first question was: do we deal with a > PSTN-replacement service or a second line (alternative communication) > service? I do not follow. Today, on the PSTN, there is no requirement, expectation, law, or rule, that a PSTN provider terminate service for someone that causes "excessive" phone calls. Otherwise, the call centers inside of my own area code, which call other phone numbers in this same area code, would be shut down. They are paying customers. > Your example is using the service expectations and legal framework of > the PSTN. Saverio's answer was different: he wants to consider second > line services first. I still contend that within those, > different rules apply. > > E.g. if I send out too much messages within LinkedIn, Skype or some > other Web 2.0 style communication platform, they will kick me off. If > you attract too many complaints for your hotmail account, you're gone. > > I'm not sure about the US situation, but here in Austria the same > legal framework which defines your rights and the carrier's duties > with respect to PSTN service also describes what kind of conduct > (e.g. telemarketing) is illegal and even tasks a government > agency with acting on complaints from users. There are similar restrictions here in the US, and a national "do not call" list which telemarketers are required to look up prior to making phone calls. However, the phone companies themselves do not enforce this restriction or requirement -- rather, it is a government agency (our Federal Communications Commission) that receives complaints and takes actions against companies that illegally make unsolicited phone calls to numbers on the 'do not call' list. > That does not apply to any fancy "Free World Dialup" knock-off > that someone might try to establish here. > > So yes, I agree with your example (though I don't know what a fancy > header would help), The headers need not be fancy, they only need to be agreed upon. If the service provider puts "Spam: Yes", but the SIP User Agent is looking for "X-Spam: 1.0", we can't have an interoperable system. I want an interoperable system. > which actually bolsters my claim that we > really need to be clear whether we're building a solution for > PSTN replacement services or just for fancy alternative services. I'm sorry, but I am unable to understand the distinction you desire, even though we have exchanged several emails on this. -d _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Feb 16 14:55:56 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBEF28C311; Sat, 16 Feb 2008 14:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpouDQFijrWk; Sat, 16 Feb 2008 14:55:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6888528C2FB; Sat, 16 Feb 2008 14:55:55 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948EA3A67AD for ; Sat, 16 Feb 2008 14:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAB6regNkZRY for ; Sat, 16 Feb 2008 14:55:51 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 325E528C325 for ; Sat, 16 Feb 2008 14:55:50 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 97C4A2C000357; Sat, 16 Feb 2008 23:55:48 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV3bbV5fh+xl; Sat, 16 Feb 2008 23:55:48 +0100 (CET) Received: by smtp0.neclab.eu (Postfix, from userid 1001) id 7ED212C009E8D; Sat, 16 Feb 2008 23:55:48 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 3833E2C000357; Sat, 16 Feb 2008 23:55:33 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 16 Feb 2008 23:53:33 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0F00@mx1.office> In-Reply-To: <20080215161045.GC13520@bofh.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] [spitstop] Context for rucus Thread-Index: Achv7e36VnDUF9cvQPGLf5ByTPvhagA/rQMg References: <20080215143513.GA13520@bofh.priv.at><5F6519BF2DE0404D99B7C75607FF76FF4D0ECC@mx1.office> <20080215161045.GC13520@bofh.priv.at> From: "Saverio Niccolini" To: "Otmar Lendl" , X-Sanitizer: This message has been sanitized! Cc: rucus@ietf.org Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi, > Sorry, but if you're restricting the discussions to case b) > and just internal or communication between trusted parties > (without transit), then the focus is so narrow that I don't > see a point in doing any work on this. The work needs to address something narrow otherwise we will never reach consensus. It is just a way to start working on this, if we think too big on a topic so controversial then it is better not to start at all. Thus better think small but achieve something... > In the "single administrative domain" case you don't write > fancy "this call is probably spit"-header into the signalling > if you detect spit, but instead you disable the account of > the offender. I think you misunderstood me: When I was referring to the single domain, I was thinking of the scenario that Hannes depicted in his draft (if you see the figure you see everything happens within a "Domain Boundary"). My point in saying that was focus on technical work needs assuming that SPIT communications are between trusted entities (to simplify the scenario and reach faster an agreement on work to be done). > In the pure bi-lateral trusted case you do the same. If you > know that this is a likely spit-call, then don't even pass it > to your peer. You are missing one point here: in the case you want to address "a", you can not simply suppress communications (not even in a single domain) because this is not legal, this why you may need to have SPIT indications (scores and user feedbacks) and apply policies (that the user needs to agree with). > That's no topic for the IETF. I start thinking you are right, but this is not something that can be decided by me and you. I am trying to find a scenario where this topic can be for IETF, if we fail I can just go back and write my papers... Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Feb 16 15:08:13 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C8128C30F; Sat, 16 Feb 2008 15:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9dGbAC0E1G3; Sat, 16 Feb 2008 15:08:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A96A3A6B5C; Sat, 16 Feb 2008 15:08:13 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494E13A6B57 for ; Sat, 16 Feb 2008 15:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVPd15LuBDir for ; Sat, 16 Feb 2008 15:08:11 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 41F4E28C2C2 for ; Sat, 16 Feb 2008 15:08:11 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id AEC4F2C009E8D; Sun, 17 Feb 2008 00:08:09 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itqrCtqPgYES; Sun, 17 Feb 2008 00:08:09 +0100 (CET) Received: by smtp0.neclab.eu (Postfix, from userid 1001) id 98B142C00C336; Sun, 17 Feb 2008 00:08:09 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 530442C009E8D; Sun, 17 Feb 2008 00:07:49 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Feb 2008 00:07:48 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0F01@mx1.office> In-Reply-To: <20080215214731.GE13520@bofh.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] [spitstop] Context for rucus Thread-Index: AchwHG3kJQkPV2miRzuhZecC1gp7hwA01BLQ References: <20080215161045.GC13520@bofh.priv.at><124401c87003$ea9930e0$c4f0200a@cisco.com><20080215194050.GD13520@bofh.priv.at><139b01c8700e$876e1250$c4f0200a@cisco.com> <20080215214731.GE13520@bofh.priv.at> From: "Saverio Niccolini" To: "Otmar Lendl" , "Dan Wing" X-Sanitizer: This message has been sanitized! Cc: rucus@ietf.org, Signaling TO Prevent SPIT Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi again, > So yes, I agree with your example (though I don't know what a > fancy header would help), which actually bolsters my claim > that we really need to be clear whether we're building a > solution for PSTN replacement services or just for fancy > alternative services. ok, you want to focus on "a: we are building a solution that assumes the same rules that PSTN has nowadays" It is fine with me as well, I just think it is going to be more complicated to get consensus on a solution if we assume too many restrictions, but I am willing to work on this Saverio > > /ol > -- > -=- Otmar Lendl -- ol@bofh.priv.at -=- > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 03:09:54 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452FD3A6CB8; Mon, 18 Feb 2008 03:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOOlT-bY770G; Mon, 18 Feb 2008 03:09:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7996D3A6CC0; Mon, 18 Feb 2008 03:09:53 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C314728C296 for ; Mon, 18 Feb 2008 03:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWSs+RzPjDVH for ; Mon, 18 Feb 2008 03:09:50 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id A79AF28C21A for ; Mon, 18 Feb 2008 03:09:50 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28040955 for rucus@ietf.org; Mon, 18 Feb 2008 11:09:47 +0000 Mime-Version: 1.0 (Apple Message framework v753) To: rucus@ietf.org Message-Id: <1F049547-5921-4664-9C74-E5739A9205A5@voxeo.com> From: Dan York Date: Mon, 18 Feb 2008 06:09:45 -0500 X-Mailer: Apple Mail (2.753) Subject: [Rucus] RUCUS web archive is now online... X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1403796909==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1403796909== Content-Type: multipart/alternative; boundary=Apple-Mail-69--459997107 --Apple-Mail-69--459997107 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI, the web archive is now working and is displaying all messages since the list began: http://www.ietf.org/mail-archive/web/rucus/current/maillist.html Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-69--459997107 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI, the web archive is now = working and is displaying all messages since the list began:

=

Regards,
Dan
--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-69--459997107-- --===============1403796909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1403796909==-- From rucus-bounces@ietf.org Mon Feb 18 04:46:39 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2495A28C3EF; Mon, 18 Feb 2008 04:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGtrPvqRTcA7; Mon, 18 Feb 2008 04:46:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB3028C3DF; Mon, 18 Feb 2008 04:46:36 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AA4228C3DF for ; Mon, 18 Feb 2008 04:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kps6HmomRKhg for ; Mon, 18 Feb 2008 04:46:35 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id CE21228C343 for ; Mon, 18 Feb 2008 04:46:33 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5EC282C01D460 for ; Mon, 18 Feb 2008 13:46:31 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFUgyYpvp+lz for ; Mon, 18 Feb 2008 13:46:31 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 416E82C000355 for ; Mon, 18 Feb 2008 13:46:26 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 13:46:25 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scoping question about rucus BoF Thread-Index: AchyLEX0kblgoiDIQYWFfoMRuO+vOw== From: "Martin Stiemerling" To: "rucus BoF" Subject: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi all, I have been looking for some information about the rucus bof and ran into Hannes' web page (http://www.tschofenig.priv.at/bof-rucus.html). I have no clue whether this page is authorative or not. Anyhow, here goes my question. I have seen the discussions on SIPPING and the SPITSTOP mailing list, plus the above mentioned web page. However, after all, I still fail in getting the intended scope of the RUCUS BoF. The title suggests the topic, but the web page just says: 1) There is a potential threat resulting from SPIT; 2) SIP identity management; 3) some hand-waving about prior art. Me personally does like to see a WG taking care of SPIT countermeasures, but (as usual) the field of SPIT is so broad that there is the need to focus. The agenda is, to be honestly, strange. Why should a Bof burn time to discuss RFC 5111? Is RUCUS not about SPIT but a test tool for RFC 5111? Martin stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 05:17:10 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9DB28C3EF; Mon, 18 Feb 2008 05:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B+XSYur+5Ms; Mon, 18 Feb 2008 05:17:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F4D28C405; Mon, 18 Feb 2008 05:16:49 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C063A6C80 for ; Mon, 18 Feb 2008 05:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qF-xHoSgcff for ; Mon, 18 Feb 2008 05:16:48 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 427A73A6CD8 for ; Mon, 18 Feb 2008 05:16:13 -0800 (PST) Received: (qmail invoked by alias); 18 Feb 2008 13:16:10 -0000 Received: from proxy4-nsn.nsn-inter.net (EHLO [217.115.75.232]) [217.115.75.232] by mail.gmx.net (mp057) with SMTP; 18 Feb 2008 14:16:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+g5H1KQVugmDeH9vh+KdCr7YjRAuhbieyeaf8qml AeZuUx0WNO1m2v Message-ID: <47B9851C.9040009@gmx.net> Date: Mon, 18 Feb 2008 15:16:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Stiemerling References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Martin, you raised a couple of points. I will try to give you a short answer now and longer answers later: * BOF Description It is currently on my private webpage (and in emails posted to the list) but it is not on an IETF page. That's quite common at this stage. * Agenda I will update the agenda as I find more speakers. Currently, I got the confirmation from Henning to speak about architectural aspects. Jim Fenton is going to give a presentation about "Lessons learned from Email Spam work" and either Bernard or Lakshminath will speak about RFC 5111. I would like to have someone from the privacy and from the XMPP/Jabber community but I do not yet have confirmations. As such, the agenda is still work in progress. Suggestions are welcome! * RFC 5111 This document is pretty now, I agree. The idea is also pretty novel for the IETF itself. Hence, the ADs thought it would be useful to have a short presentation by the authors of that RFC to explain the community that an Exploratory Group actually is. I think that's a good idea since I believe around 90% of the folks in the room have never heard about this concept before. * Scope As indicated by Cullen in his mail the scope has be made precisely. We should use the mailing list for doing so. I also understand that most people are working on draft updates during these too weeks. Hence, I do not expect too much feedback before the draft submission deadlines are over. One thing I got as input was that we should not investigate anything relating to the interpretation of RTP. The IAB thought that this is very much a research issue and I agree with their assessment. Ciao Hannes Martin Stiemerling wrote: > Hi all, > > I have been looking for some information about the rucus bof and ran into Hannes' web page (http://www.tschofenig.priv.at/bof-rucus.html). I have no clue whether this page is authorative or not. Anyhow, here goes my question. > > I have seen the discussions on SIPPING and the SPITSTOP mailing list, plus the above mentioned web page. However, after all, I still fail in getting the intended scope of the RUCUS BoF. The title suggests the topic, but the web page just says: > 1) There is a potential threat resulting from SPIT; > 2) SIP identity management; > 3) some hand-waving about prior art. > > Me personally does like to see a WG taking care of SPIT countermeasures, but (as usual) the field of SPIT is so broad that there is the need to focus. > > The agenda is, to be honestly, strange. Why should a Bof burn time to discuss RFC 5111? > Is RUCUS not about SPIT but a test tool for RFC 5111? > > Martin > > > stiemerling@nw.neclab.eu <== NEW ADDRESS > > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 06:01:48 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D73C28C3DE; Mon, 18 Feb 2008 06:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.34 X-Spam-Level: X-Spam-Status: No, score=0.34 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf6xvjl9OxRu; Mon, 18 Feb 2008 06:01:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A16428C3A8; Mon, 18 Feb 2008 06:01:42 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F5428C3A0 for ; Mon, 18 Feb 2008 06:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1CYRNjuSBsh for ; Mon, 18 Feb 2008 06:01:39 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 3C59428C0DA for ; Mon, 18 Feb 2008 06:01:33 -0800 (PST) Received: from [75.69.76.232] (account dyork HELO [192.168.1.7]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28042456; Mon, 18 Feb 2008 14:01:29 +0000 In-Reply-To: <47B9851C.9040009@gmx.net> References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> <47B9851C.9040009@gmx.net> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Dan York Date: Mon, 18 Feb 2008 09:01:27 -0500 To: Hannes.Tschofenig@gmx.net X-Mailer: Apple Mail (2.753) Cc: rucus BoF , Martin Stiemerling Subject: Re: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0225838073==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============0225838073== Content-Type: multipart/alternative; boundary=Apple-Mail-77--449695323 --Apple-Mail-77--449695323 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Martin, Just to add on to Hannes' points, to me the point of the RUCUS BOF is really to look at the overall *architecture* for realtime communications over SIP and address questions such as: - can we in fact establish an overall framework for dealing with SPIT/spam? - what are the various pieces of that framework? - what of the existing IETF work can we simply use with no modification? (for instance, perhaps the various forms of SIP Identity) - in what areas of the framework can we define the problem and simply need to write some documents and formalize current thinking? - in what areas of the framework do we need more research? I'm not naive enough to think we'll solve all of that in Philadelphia, but the point to me is to get the various people interested in the problem of SPIT all in one room and bash this stuff out and see where we need to go next. If you look at RFC 5039 - http://tools.ietf.org/rfcmarkup?doc=rfc5039 - there is no lack of proposed solutions out there to combat SPIT. There are a good number of folks working in this space. I also don't expect we'll ever see a "silver bullet" solution that mystically makes the problem go away. There's a zillion different network configurations out there in deployed networks and each one is different enough from others that in the end I'm sure we'll end up with a range of solutions that are applicable to different kind of networks. Where I believe we in the IETF can add value is to help put together the pieces (and create new ones if necessary) that provide an overall framework to guide network administrators in protecting their networks. Jonathan and Cullen propose a starting point in RFC 5039 for a framework: 1. Strong Identity 2. White Lists 3. Solve the Introduction Problem 4. Don't Wait Until It's Too Late In my mind the work of RUCUS is to look at how to take that (and other work) and turn it into an actual framework/architecture. We've had a lot of I-Ds that propose individual point solutions (and have had BOF proposals in the past that intended to focus on those solutions). This is to look at how we put it all together. At least, that is *my* perspective and why I support this BOF. My 2 cents, Dan On Feb 18, 2008, at 8:16 AM, Hannes Tschofenig wrote: > Hi Martin, > > you raised a couple of points. I will try to give you a short > answer now > and longer answers later: > > * BOF Description > > It is currently on my private webpage (and in emails posted to the > list) > but it is not on an IETF page. > That's quite common at this stage. > > * Agenda > > I will update the agenda as I find more speakers. Currently, I got the > confirmation from Henning to speak about architectural aspects. Jim > Fenton is going to give a presentation about "Lessons learned from > Email > Spam work" and either Bernard or Lakshminath will speak about RFC > 5111. > I would like to have someone from the privacy and from the XMPP/Jabber > community but I do not yet have confirmations. > > As such, the agenda is still work in progress. Suggestions are > welcome! > > * RFC 5111 > > This document is pretty now, I agree. The idea is also pretty novel > for > the IETF itself. > Hence, the ADs thought it would be useful to have a short presentation > by the authors of that RFC to explain the community that an > Exploratory > Group actually is. > I think that's a good idea since I believe around 90% of the folks in > the room have never heard about this concept before. > > * Scope > > As indicated by Cullen in his mail the scope has be made precisely. We > should use the mailing list for doing so. I also understand that most > people are working on draft updates during these too weeks. Hence, > I do > not expect too much feedback before the draft submission deadlines are > over. > > One thing I got as input was that we should not investigate anything > relating to the interpretation of RTP. The IAB thought that this is > very > much a research issue and I agree with their assessment. > > Ciao > Hannes > > > Martin Stiemerling wrote: >> Hi all, >> >> I have been looking for some information about the rucus bof and >> ran into Hannes' web page (http://www.tschofenig.priv.at/bof- >> rucus.html). I have no clue whether this page is authorative or >> not. Anyhow, here goes my question. >> >> I have seen the discussions on SIPPING and the SPITSTOP mailing >> list, plus the above mentioned web page. However, after all, I >> still fail in getting the intended scope of the RUCUS BoF. The >> title suggests the topic, but the web page just says: >> 1) There is a potential threat resulting from SPIT; >> 2) SIP identity management; >> 3) some hand-waving about prior art. >> >> Me personally does like to see a WG taking care of SPIT >> countermeasures, but (as usual) the field of SPIT is so broad that >> there is the need to focus. >> >> The agenda is, to be honestly, strange. Why should a Bof burn time >> to discuss RFC 5111? >> Is RUCUS not about SPIT but a test tool for RFC 5111? >> >> Martin >> >> >> stiemerling@nw.neclab.eu <== NEW ADDRESS >> >> NEC Laboratories Europe - Network Research Division >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >> Road, London W3 6BL | Registered in England 2832014 >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> http://www.ietf.org/mailman/listinfo/rucus >> > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-77--449695323 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Martin,

Just to = add on to Hannes' points, to me the point of the RUCUS BOF is really to = look at the overall *architecture* for realtime communications over SIP = and =A0address questions such as:
=A0=A0- can we in fact = establish an overall framework for dealing with SPIT/spam?
=A0=A0= - what are the various pieces of that framework?
=A0=A0- what = of the existing IETF work can we simply use with no modification? (for = instance, perhaps the various forms of SIP Identity)
=A0=A0- = in what areas of the framework can we define the problem and simply need = to write some documents and formalize current thinking?
=A0=A0- = in what areas of the framework do we need more research?

I'm not naive enough to = think we'll solve all of that in Philadelphia, but the point to me is=A0to= get the various people interested in the problem of SPIT all in one = room and bash this stuff out and see where we need to go = next.

If you = look at RFC 5039 -=A0http://tools.ietf.o= rg/rfcmarkup?doc=3Drfc5039 - there is no lack of proposed solutions = out there to combat SPIT. =A0There are a good number of folks working in = this space. I also don't expect we'll ever see a "silver bullet" = solution that mystically makes the problem go away. There's a zillion = different network configurations out there in deployed networks and each = one is different enough from others that in the end I'm sure we'll end = up with a range of solutions that are applicable to different kind of = networks.

Where I believe we in the = IETF can add value is to help put together the pieces (and create new = ones if necessary) that provide an overall framework to guide network = administrators in protecting their networks. =A0 Jonathan and Cullen = propose a starting point in RFC 5039 for a framework:

1. Strong = Identity
2. White Lists
3. Solve the Introduction = Problem
4. Don't Wait Until It's Too Late

In my mind the work of = RUCUS is to look at how to take that (and other work) and turn it into = an actual framework/architecture.=A0We've had a lot of I-Ds that propose = individual point solutions (and have had BOF proposals in the past that = intended to focus on those solutions). =A0This is to look at how we put = it all together. =A0At least, that is *my* perspective and why I support = this BOF.

My = 2 cents,
Dan

On Feb 18, 2008, = at 8:16 AM, Hannes Tschofenig wrote:

Hi Martin,

you raised a couple of points. I = will try to give you a short answer now=A0
and = longer answers later:
* BOF Description

It is = currently on my private webpage (and in emails posted to the list)=A0
but it = is not on an IETF page.
That's quite = common at this stage.
* Agenda

I will = update the agenda as I find more speakers. Currently, I got the=A0
=A0
Fenton is going to give a presentation about = "Lessons learned from Email=A0
Spam = work" and either Bernard or Lakshminath will speak about RFC 5111.=A0
I would = like to have someone from the privacy and from the XMPP/Jabber=A0

As such, = the agenda is still work in progress. Suggestions are welcome!

* RFC = 5111

This document is pretty now, I agree. The idea is = also pretty novel for=A0
the IETF = itself.
Hence, the ADs thought it would = be useful to have a short presentation=A0
by the = authors of that RFC to explain the community that an Exploratory=A0
Group = actually is.
I think that's a good idea since = I believe around 90% of the folks in=A0
the room = have never heard about this concept before.

* = Scope

As indicated by Cullen in his mail the scope has be = made precisely. We=A0
should use the mailing list for doing so. I also = understand that most=A0
people = are working on draft updates during these too weeks. Hence, I do=A0
not = expect too much feedback before the draft submission deadlines are=A0

One thing I got as input was that we should not = investigate anything=A0
relating = to the interpretation of RTP. The IAB thought that this is very=A0
much a = research issue and I agree with their assessment.

Hannes


Martin = Stiemerling wrote:
Hi all,

I have been looking for some = information about the rucus bof and ran into Hannes' web page (http://www.tschofenig.co= m/bof-rucus.html). I have no clue whether this page is authorative = or not. Anyhow, here goes my question.

I have seen = the discussions on SIPPING and the SPITSTOP mailing list, plus the above = mentioned web page. However, after all, I still fail in getting the = intended scope of the RUCUS BoF. The title suggests the topic, but the = web page just says:
1) There is a potential = threat resulting from SPIT;
2) SIP = identity management;
3) some hand-waving about = prior art.=A0

Me = personally does like to see a WG taking care of SPIT countermeasures, = but (as usual) the field of SPIT is so broad that there is the need to = focus.=A0

The = agenda is, to be honestly, strange. Why should a Bof burn time to = discuss RFC 5111?
Is RUCUS not about SPIT but a = test tool for RFC 5111?

=A0 Martin


stiemerling@nw.neclab.eu = =A0 <=3D=3D NEW = ADDRESS

NEC Laboratories Europe - Network Research = Division
NEC Europe Limited | Registered = Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=A0
Rucus mailing list


Rucus mailing list

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=
= --Apple-Mail-77--449695323-- --===============0225838073== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============0225838073==-- From rucus-bounces@ietf.org Mon Feb 18 06:30:27 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470BB28C495; Mon, 18 Feb 2008 06:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjLhKZzoMOTb; Mon, 18 Feb 2008 06:30:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB6228C493; Mon, 18 Feb 2008 06:27:46 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301B628C410 for ; Mon, 18 Feb 2008 06:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8pysYW802Dk for ; Mon, 18 Feb 2008 06:27:43 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id F2FAB28C523 for ; Mon, 18 Feb 2008 06:23:44 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A0D2B2C01D460; Mon, 18 Feb 2008 15:23:42 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG0-UhluZZEI; Mon, 18 Feb 2008 15:23:42 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 8DA2C2C000355; Mon, 18 Feb 2008 15:23:32 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 15:23:31 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0FD8@mx1.office> In-Reply-To: <47B9851C.9040009@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Scoping question about rucus BoF Thread-Index: AchyMODRL3xjDoC2S6OFQNqAjNU9ZgACM7sQ References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> <47B9851C.9040009@gmx.net> From: "Saverio Niccolini" To: , "Martin Stiemerling" Cc: rucus BoF Subject: Re: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi, > One thing I got as input was that we should not investigate anything > relating to the interpretation of RTP. The IAB thought that > this is very > much a research issue and I agree with their assessment. Can you be a bit more precise about "the interpretation of RTP"? I did not get what you mean by that. Cheers, Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 06:59:29 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58FFF28C32B; Mon, 18 Feb 2008 06:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPZlBeeLKB58; Mon, 18 Feb 2008 06:59:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A25E3A6BB9; Mon, 18 Feb 2008 06:59:28 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9FF3A6BB9 for ; Mon, 18 Feb 2008 06:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqkG2PzOw2vm for ; Mon, 18 Feb 2008 06:59:26 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 12F543A67F7 for ; Mon, 18 Feb 2008 06:59:26 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id B0E8E2C002B4A; Mon, 18 Feb 2008 15:59:23 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZubUZrBFv1z; Mon, 18 Feb 2008 15:59:23 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 912182C000355; Mon, 18 Feb 2008 15:59:13 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 15:59:12 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0FE8@mx1.office> In-Reply-To: <47B9851C.9040009@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Scoping question about rucus BoF Thread-Index: AchyMHKxDIKgXgl3S4+6lI8MpZRemQADKSQA References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> <47B9851C.9040009@gmx.net> From: "Martin Stiemerling" To: Cc: rucus BoF Subject: Re: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Hannes, all, > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, February 18, 2008 2:16 PM > To: Martin Stiemerling > Cc: rucus BoF > Subject: Re: [Rucus] Scoping question about rucus BoF > > Hi Martin, > > you raised a couple of points. I will try to give you a short > answer now and longer answers later: > > * BOF Description > > It is currently on my private webpage (and in emails posted > to the list) but it is not on an IETF page. > That's quite common at this stage. I do know this ;) I was just wondering about not finding anything on the several email lists related to rucus. > > * Agenda > > I will update the agenda as I find more speakers. Currently, > I got the confirmation from Henning to speak about > architectural aspects. Jim Fenton is going to give a > presentation about "Lessons learned from Email Spam work" and > either Bernard or Lakshminath will speak about RFC 5111. Could be a good idea. > I would like to have someone from the privacy and from the > XMPP/Jabber community but I do not yet have confirmations. I don't see the reason for this. > > As such, the agenda is still work in progress. Suggestions > are welcome! Here is a change proposal for the agenda (moving "legal" things first) and giving more space for the chair to explain what's up in the BoF: Title Duration --------------------------- ----------- Introduction (chairs, 15) Intro of RFC 5111 (chairs/ADs, 5) RFC 5039 Overview (TBD, 10) Architectural Considerations (Tschofenig, 30) (based on draft-tschofenig-sipping-framework-spit-reduction-02.txt draft-niccolini-sipping-spitstop-00.txt ) Discussion (all, remaining) Warp-up last 10 mins ------------ > > * RFC 5111 > > This document is pretty now, I agree. The idea is also pretty > novel for the IETF itself. > Hence, the ADs thought it would be useful to have a short > presentation by the authors of that RFC to explain the > community that an Exploratory Group actually is. > I think that's a good idea since I believe around 90% of the > folks in the room have never heard about this concept before. I would shift it to the beginning, as this will definitely impact the discussions. Also, it is more useful to put the planable things upfront, i.e., getting free time at the end for the necessary discussions. > > * Scope > > As indicated by Cullen in his mail the scope has be made > precisely. We should use the mailing list for doing so. I > also understand that most people are working on draft updates > during these too weeks. Hence, I do not expect too much > feedback before the draft submission deadlines are over. Yes, I agree that most people are busy with writing drafts. And my intention was to give the whole scoping discussions a kick-start ( or slow-start). My brief scoping proposal for rucus (open for discussions!): - SPIT as threat for SIP is foreseeable, but not fully understood to all extend. - RFC 5039 is used as problem statement for SPIT - rucus should define an architecture/framework for SIP to mitigate SPIT - rucus should produce a set of requirements how to mitigate SPIT - rucus output used as input to sipping > > One thing I got as input was that we should not investigate > anything relating to the interpretation of RTP. The IAB > thought that this is very much a research issue and I agree > with their assessment. I assume this refers to investigation of RTP playload, i.e. voice/video? Martin stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 07:08:37 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8638728C360; Mon, 18 Feb 2008 07:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXXfg3GZvH+r; Mon, 18 Feb 2008 07:08:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A3F28C152; Mon, 18 Feb 2008 07:08:36 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1184128C152 for ; Mon, 18 Feb 2008 07:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIU+G9jgaSRO for ; Mon, 18 Feb 2008 07:08:35 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1CEA228C2AA for ; Mon, 18 Feb 2008 07:08:34 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id BC1372C01D460 for ; Mon, 18 Feb 2008 16:08:31 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSmv8fX5u3ED for ; Mon, 18 Feb 2008 16:08:31 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id ABFA42C00C336 for ; Mon, 18 Feb 2008 16:08:26 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 16:08:26 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0FED@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reading list for BoF Thread-Index: AchyQBxZDSqWpfgaSdKzPXbwMUshrA== From: "Martin Stiemerling" To: "rucus BoF" Subject: [Rucus] Reading list for BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi, I'm currently trying to get an overview about what has happened in the field of SPIT mitigation, i.e., editing a useful reading list for the rucus bof. Some possible documents to read: - RFC 5039 - SIP Extensions for SPIT identification (draft-niccolini-sipping-feedback-spit-03) - Signaling TO Prevent SPIT (SPITSTOP) Reference Scenario draft-niccolini-sipping-spitstop-01) - Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA) based Robot Challenges for the Session Initiation Protocol (SIP) (draft-tschofenig-sipping-captcha-00.txt) - A Framework to tackle Spam and Unwanted Communication for Internet Telephony (draft-tschofenig-sipping-framework-spit-reduction-02.txt) A Document Format for Expressing Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony (draft-tschofenig-sipping-spit-policy-02.txt) - Spam feedback for SIP (draft-niccolini-sipping-spam-feedback-00.txt) - Spam Score for SIP (draft-wing-sipping-spam-score-01.txt) Martin stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 07:10:05 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E9928C380; Mon, 18 Feb 2008 07:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=-1.223, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZd7vAO2Pzkx; Mon, 18 Feb 2008 07:10:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5FF28C2AA; Mon, 18 Feb 2008 07:10:04 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51EE13A6C1F for ; Mon, 18 Feb 2008 07:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NwzcrJQL1vT for ; Mon, 18 Feb 2008 07:10:00 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 49E6B3A67F4 for ; Mon, 18 Feb 2008 07:10:00 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1IF9uB7026832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 16:09:56 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1IF9ogj017359; Mon, 18 Feb 2008 16:09:54 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Feb 2008 16:09:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 16:09:50 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB798528@DEMUEXC012.nsn-intra.net> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0FED@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Reading list for BoF Thread-Index: AchyQBxZDSqWpfgaSdKzPXbwMUshrAAABwVA References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FED@mx1.office> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Martin Stiemerling" , "rucus BoF" X-OriginalArrivalTime: 18 Feb 2008 15:09:50.0778 (UTC) FILETIME=[4EEE69A0:01C87240] Subject: Re: [Rucus] Reading list for BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org FYI, we are going to have more documents after the draft submission deadlin= e. = > -----Urspr=FCngliche Nachricht----- > Von: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] = > Im Auftrag von ext Martin Stiemerling > Gesendet: Montag, 18. Februar 2008 17:08 > An: rucus BoF > Betreff: [Rucus] Reading list for BoF > = > = > Hi, > = > I'm currently trying to get an overview about what has = > happened in the field of SPIT mitigation, i.e., editing a = > useful reading list for the rucus bof. = > = > Some possible documents to read: > - RFC 5039 > - SIP Extensions for SPIT identification = > (draft-niccolini-sipping-feedback-spit-03) > - Signaling TO Prevent SPIT (SPITSTOP) Reference Scenario = > draft-niccolini-sipping-spitstop-01) > - Completely Automated Public Turing Test to Tell Computers = > and Humans Apart (CAPTCHA) based Robot Challenges for the = > Session Initiation Protocol (SIP) = > (draft-tschofenig-sipping-captcha-00.txt) > - A Framework to tackle Spam and Unwanted Communication for = > Internet Telephony = > (draft-tschofenig-sipping-framework-spit-reduction-02.txt) > A Document Format for Expressing Authorization Policies to tackle Spam > and Unwanted Communication for Internet Telephony = > (draft-tschofenig-sipping-spit-policy-02.txt) > - Spam feedback for SIP (draft-niccolini-sipping-spam-feedback-00.txt) > - Spam Score for SIP (draft-wing-sipping-spam-score-01.txt) > = > = > Martin > = > = > stiemerling@nw.neclab.eu <=3D=3D NEW ADDRESS > = > NEC Laboratories Europe - Network Research Division > = > NEC Europe Limited | Registered Office: NEC House, 1 Victoria = > Road, London W3 6BL | Registered in England 2832014 = > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > = _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 07:27:09 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF2628C3BB; Mon, 18 Feb 2008 07:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR0cRh8i80vx; Mon, 18 Feb 2008 07:27:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AFF328C31C; Mon, 18 Feb 2008 07:27:08 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555233A6C59 for ; Mon, 18 Feb 2008 07:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPvlB1j0YEWN for ; Mon, 18 Feb 2008 07:27:07 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 9805128C31C for ; Mon, 18 Feb 2008 07:27:06 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 46AD62C00C336; Mon, 18 Feb 2008 16:27:04 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzurWpw8eThY; Mon, 18 Feb 2008 16:27:04 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 27B642C000355; Mon, 18 Feb 2008 16:26:54 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 16:26:50 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0FF5@mx1.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Scoping question about rucus BoF Thread-Index: AchyNun8bu+7d8MHQ9msKKigUZ1+6wACnqbA References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office><47B9851C.9040009@gmx.net> From: "Martin Stiemerling" To: "Dan York" Cc: rucus BoF Subject: Re: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dan, I see us both on the same line. Thanks, Martin > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Dan York > Sent: Monday, February 18, 2008 3:01 PM > To: Hannes.Tschofenig@gmx.net > Cc: rucus BoF; Martin Stiemerling > Subject: Re: [Rucus] Scoping question about rucus BoF > > Martin, > > Just to add on to Hannes' points, to me the point of the > RUCUS BOF is really to look at the overall *architecture* for > realtime communications over SIP and address questions such as: > - can we in fact establish an overall framework for dealing > with SPIT/spam? > - what are the various pieces of that framework? > - what of the existing IETF work can we simply use with no > modification? (for instance, perhaps the various forms of SIP > Identity) > - in what areas of the framework can we define the problem > and simply need to write some documents and formalize current > thinking? > - in what areas of the framework do we need more research? > > I'm not naive enough to think we'll solve all of that in > Philadelphia, but the point to me is to get the various > people interested in the problem of SPIT all in one room and > bash this stuff out and see where we need to go next. > > If you look at RFC 5039 - > http://tools.ietf.org/rfcmarkup?doc=rfc5039 - there is no > lack of proposed solutions out there to combat SPIT. There > are a good number of folks working in this space. I also > don't expect we'll ever see a "silver bullet" solution that > mystically makes the problem go away. There's a zillion > different network configurations out there in deployed > networks and each one is different enough from others that in > the end I'm sure we'll end up with a range of solutions that > are applicable to different kind of networks. > > Where I believe we in the IETF can add value is to help put > together the pieces (and create new ones if necessary) that > provide an overall framework to guide network administrators > in protecting their networks. Jonathan and Cullen propose a > starting point in RFC 5039 for a framework: > > 1. Strong Identity > 2. White Lists > 3. Solve the Introduction Problem > 4. Don't Wait Until It's Too Late > > In my mind the work of RUCUS is to look at how to take that > (and other work) and turn it into an actual > framework/architecture. We've had a lot of I-Ds that propose > individual point solutions (and have had BOF proposals in the > past that intended to focus on those solutions). This is to > look at how we put it all together. At least, that is *my* > perspective and why I support this BOF. > > My 2 cents, > Dan > > On Feb 18, 2008, at 8:16 AM, Hannes Tschofenig wrote: > > > Hi Martin, > > you raised a couple of points. I will try to give you a > short answer now > and longer answers later: > > * BOF Description > > It is currently on my private webpage (and in emails > posted to the list) > but it is not on an IETF page. > That's quite common at this stage. > > * Agenda > > I will update the agenda as I find more speakers. > Currently, I got the > confirmation from Henning to speak about architectural > aspects. Jim > Fenton is going to give a presentation about "Lessons > learned from Email > Spam work" and either Bernard or Lakshminath will speak > about RFC 5111. > I would like to have someone from the privacy and from > the XMPP/Jabber > community but I do not yet have confirmations. > > As such, the agenda is still work in progress. > Suggestions are welcome! > > * RFC 5111 > > This document is pretty now, I agree. The idea is also > pretty novel for > the IETF itself. > Hence, the ADs thought it would be useful to have a > short presentation > by the authors of that RFC to explain the community > that an Exploratory > Group actually is. > I think that's a good idea since I believe around 90% > of the folks in > the room have never heard about this concept before. > > * Scope > > As indicated by Cullen in his mail the scope has be > made precisely. We > should use the mailing list for doing so. I also > understand that most > people are working on draft updates during these too > weeks. Hence, I do > not expect too much feedback before the draft > submission deadlines are > over. > > One thing I got as input was that we should not > investigate anything > relating to the interpretation of RTP. The IAB thought > that this is very > much a research issue and I agree with their assessment. > > Ciao > Hannes > > > Martin Stiemerling wrote: > > Hi all, > > I have been looking for some information about > the rucus bof and ran into Hannes' web page > (http://www.tschofenig.priv.at/bof-rucus.html). I have no clue > whether this page is authorative or not. Anyhow, here goes my > question. > > I have seen the discussions on SIPPING and the > SPITSTOP mailing list, plus the above mentioned web page. > However, after all, I still fail in getting the intended > scope of the RUCUS BoF. The title suggests the topic, but the > web page just says: > 1) There is a potential threat resulting from SPIT; > 2) SIP identity management; > 3) some hand-waving about prior art. > > Me personally does like to see a WG taking care > of SPIT countermeasures, but (as usual) the field of SPIT is > so broad that there is the need to focus. > > The agenda is, to be honestly, strange. Why > should a Bof burn time to discuss RFC 5111? > Is RUCUS not about SPIT but a test tool for RFC 5111? > > Martin > > > stiemerling@nw.neclab.eu <== NEW ADDRESS > > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC > House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > > stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 07:30:56 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F343A67F7; Mon, 18 Feb 2008 07:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qGY5mS5UTG2; Mon, 18 Feb 2008 07:30:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A99E28C3C3; Mon, 18 Feb 2008 07:30:48 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5413A6BB9 for ; Mon, 18 Feb 2008 07:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiN+-0z6cNwb for ; Mon, 18 Feb 2008 07:30:45 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 40E2728C349 for ; Mon, 18 Feb 2008 07:29:46 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id E7CB32C002B48 for ; Mon, 18 Feb 2008 16:29:40 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bwcv3+j7rVlN for ; Mon, 18 Feb 2008 16:29:40 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id CDB902C000355 for ; Mon, 18 Feb 2008 16:29:35 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 16:29:35 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D0FF6@mx1.office> In-Reply-To: <5FB585F183235B42A9E70095055136FB798528@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Reading list for BoF Thread-Index: AchyQBxZDSqWpfgaSdKzPXbwMUshrAAABwVAAABwSbA= References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FED@mx1.office> <5FB585F183235B42A9E70095055136FB798528@DEMUEXC012.nsn-intra.net> From: "Saverio Niccolini" To: "rucus BoF" Subject: Re: [Rucus] Reading list for BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi, there are already some drafts out: -- new version for SPITSTOP draft (-01) http://tools.ietf.org/html/draft-niccolini-sipping-spitstop-01 -- new version of the spam score draft (-01) http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 -- new draft on spam score semantics (-00) http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam-score-semant= ics-00.txt -- new draft on SIP spam feedback (-00) http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 Also an update to the CAPTCHA draft based on recent discussion will follow, link will be posted as soons as it is submitted. Cheers, Saverio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division = Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 = = > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] = > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Monday, February 18, 2008 4:10 PM > To: Martin Stiemerling; rucus BoF > Subject: Re: [Rucus] Reading list for BoF > = > FYI, we are going to have more documents after the draft = > submission deadline. = > = > = > = > > -----Urspr=FCngliche Nachricht----- > > Von: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] = > Im Auftrag = > > von ext Martin Stiemerling > > Gesendet: Montag, 18. Februar 2008 17:08 > > An: rucus BoF > > Betreff: [Rucus] Reading list for BoF > > = > > = > > Hi, > > = > > I'm currently trying to get an overview about what has = > happened in the = > > field of SPIT mitigation, i.e., editing a useful reading = > list for the = > > rucus bof. > > = > > Some possible documents to read: > > - RFC 5039 > > - SIP Extensions for SPIT identification > > (draft-niccolini-sipping-feedback-spit-03) > > - Signaling TO Prevent SPIT (SPITSTOP) Reference Scenario > > draft-niccolini-sipping-spitstop-01) > > - Completely Automated Public Turing Test to Tell Computers = > and Humans = > > Apart (CAPTCHA) based Robot Challenges for the Session Initiation = > > Protocol (SIP) > > (draft-tschofenig-sipping-captcha-00.txt) > > - A Framework to tackle Spam and Unwanted Communication for = > > Internet Telephony = > > (draft-tschofenig-sipping-framework-spit-reduction-02.txt) > > A Document Format for Expressing Authorization Policies to = > tackle Spam = > > and Unwanted Communication for Internet Telephony > > (draft-tschofenig-sipping-spit-policy-02.txt) > > - Spam feedback for SIP = > (draft-niccolini-sipping-spam-feedback-00.txt) > > - Spam Score for SIP (draft-wing-sipping-spam-score-01.txt) > > = > > = > > Martin > > = > > = > > stiemerling@nw.neclab.eu <=3D=3D NEW ADDRESS > > = > > NEC Laboratories Europe - Network Research Division > > = > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria = > > Road, London W3 6BL | Registered in England 2832014 = > > _______________________________________________ > > Rucus mailing list > > Rucus@ietf.org > > http://www.ietf.org/mailman/listinfo/rucus > > = > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > = _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 07:34:57 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4A128C4D4; Mon, 18 Feb 2008 07:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4IWvvuQ8CAv; Mon, 18 Feb 2008 07:34:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F61328C416; Mon, 18 Feb 2008 07:34:21 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231C228C416 for ; Mon, 18 Feb 2008 07:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUfKflKesZ6K for ; Mon, 18 Feb 2008 07:34:19 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6EEA028C48F for ; Mon, 18 Feb 2008 07:33:49 -0800 (PST) Received: (qmail invoked by alias); 18 Feb 2008 15:33:46 -0000 Received: from proxy2-nsn.nsn-inter.net (EHLO [217.115.75.230]) [217.115.75.230] by mail.gmx.net (mp006) with SMTP; 18 Feb 2008 16:33:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+mt50AgSimb7Ed+/bdPAHZkZ5w9ozlOBz/MQ4l4X ynPGanG8Ngkyh8 Message-ID: <47B9A55A.9010002@gmx.net> Date: Mon, 18 Feb 2008 17:33:46 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Stiemerling References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> <47B9851C.9040009@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF4D0FE8@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0FE8@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Martin Martin Stiemerling wrote: > Hi Hannes, all, > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, February 18, 2008 2:16 PM >> To: Martin Stiemerling >> Cc: rucus BoF >> Subject: Re: [Rucus] Scoping question about rucus BoF >> >> Hi Martin, >> >> you raised a couple of points. I will try to give you a short >> answer now and longer answers later: >> >> * BOF Description >> >> It is currently on my private webpage (and in emails posted >> to the list) but it is not on an IETF page. >> That's quite common at this stage. >> > > I do know this ;) > > I was just wondering about not finding anything on the several email lists related to rucus. > > When you register for the mailing list then you can find the link to the text. >> * Agenda >> >> I will update the agenda as I find more speakers. Currently, >> I got the confirmation from Henning to speak about >> architectural aspects. Jim Fenton is going to give a >> presentation about "Lessons learned from Email Spam work" and >> either Bernard or Lakshminath will speak about RFC 5111. >> > > Could be a good idea. > > >> I would like to have someone from the privacy and from the >> XMPP/Jabber community but I do not yet have confirmations. >> > > I don't see the reason for this. > > Interesting. There are a couple of privacy related questions that come up with regard to this topic in the past. Learning something about this would be helpful. The XMPP/Jabber work is as important as hearing about the Email Anti-Spam work given that XMPP/Jabber is about real-time communication and many of the work we are doing here right now has been done by these folks years ago already. Would be interesting to hear what their big picture was (since this is not described in any of their documents). >> As such, the agenda is still work in progress. Suggestions >> are welcome! >> > > Here is a change proposal for the agenda (moving "legal" things first) and giving more space for the chair to explain what's up in the BoF: > > Title Duration > --------------------------- ----------- > Introduction (chairs, 15) > Intro of RFC 5111 (chairs/ADs, 5) > > RFC 5039 Overview (TBD, 10) > > Architectural Considerations (Tschofenig, 30) > (based on > draft-tschofenig-sipping-framework-spit-reduction-02.txt > draft-niccolini-sipping-spitstop-00.txt ) > > > > > Discussion (all, remaining) > Warp-up last 10 mins > ------------ > > > The reason why I put the RFC 5111 presentation to the end was it relates to the charter discussion. >> >> * RFC 5111 >> >> This document is pretty now, I agree. The idea is also pretty >> novel for the IETF itself. >> Hence, the ADs thought it would be useful to have a short >> presentation by the authors of that RFC to explain the >> community that an Exploratory Group actually is. >> I think that's a good idea since I believe around 90% of the >> folks in the room have never heard about this concept before. >> > > I would shift it to the beginning, as this will definitely impact the discussions. Also, it is more useful to put the planable things upfront, i.e., getting free time at the end for the necessary discussions. > > See above but I am easy to convince. >> * Scope >> >> As indicated by Cullen in his mail the scope has be made >> precisely. We should use the mailing list for doing so. I >> also understand that most people are working on draft updates >> during these too weeks. Hence, I do not expect too much >> feedback before the draft submission deadlines are over. >> > > Yes, I agree that most people are busy with writing drafts. And my intention was to give the whole scoping discussions a kick-start ( or slow-start). > > My brief scoping proposal for rucus (open for discussions!): > - SPIT as threat for SIP is foreseeable, but not fully understood to all extend. > - RFC 5039 is used as problem statement for SPIT > - rucus should define an architecture/framework for SIP to mitigate SPIT > I intentionally used the term "reducing unwanted communication" in the BoF proposal since I believe we are not only talking about SPIT. > - rucus should produce a set of requirements how to mitigate SPIT > In my past IETF work I got the impression that a lot of the work on requirements was wasted time (btw, discussion about terminology was useful since it often ended up in the same document). I think once we roughly agree on the big picture then the work on the solutions is "easy". > - rucus output used as input to sipping > > Whether any subsequent work should be done in SIPPING is something I do not worry about at this point in time (also since it is up to the ADs to decide). > >> One thing I got as input was that we should not investigate >> anything relating to the interpretation of RTP. The IAB >> thought that this is very much a research issue and I agree >> with their assessment. >> > > I assume this refers to investigation of RTP playload, i.e. voice/video? > I will respond to this issue in a separate mail. Ciao Hannes > Martin > > stiemerling@nw.neclab.eu <== NEW ADDRESS > > NEC Laboratories Europe - Network Research Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 07:38:00 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0024028C49F; Mon, 18 Feb 2008 07:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBH3RfaMXwIq; Mon, 18 Feb 2008 07:37:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376B528C45F; Mon, 18 Feb 2008 07:37:52 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B949828C432 for ; Mon, 18 Feb 2008 07:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV3a9gaYWO11 for ; Mon, 18 Feb 2008 07:37:47 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0CEC128C4FE for ; Mon, 18 Feb 2008 07:35:31 -0800 (PST) Received: (qmail invoked by alias); 18 Feb 2008 15:35:28 -0000 Received: from proxy2-nsn.nsn-inter.net (EHLO [217.115.75.230]) [217.115.75.230] by mail.gmx.net (mp006) with SMTP; 18 Feb 2008 16:35:28 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+/2cBQn1i/oSQK6tlq/jzE2u8C4fSr1agzPaHygc 3IRa9sq7pett6K Message-ID: <47B9A5C0.5080704@gmx.net> Date: Mon, 18 Feb 2008 17:35:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: rucus BoF X-Y-GMX-Trusted: 0 Subject: [Rucus] [Fwd: I-D Action:draft-schwartz-rucus-problem-statement-01.txt] X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org FYI -------- Original Message -------- Subject: I-D Action:draft-schwartz-rucus-problem-statement-01.txt Date: Mon, 18 Feb 2008 07:15:01 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RUCUS Problem Statement Author(s) : D. Schwartz Filename : draft-schwartz-rucus-problem-statement-01.txt Pages : 8 Date : 2008-02-18 SIP is being used more an more today for everyday communication purposes. With this widespread adoption comes the inevitability of abuse. This document describes the problems that fit into the category of "unwanted Communication". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schwartz-rucus-problem-statement-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schwartz-rucus-problem-statement-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schwartz-rucus-problem-statement-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 07:40:48 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8EF3A6CE2; Mon, 18 Feb 2008 07:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXAOEwNvMFG6; Mon, 18 Feb 2008 07:40:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27023A6C1F; Mon, 18 Feb 2008 07:40:45 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA6C3A6CE2 for ; Mon, 18 Feb 2008 07:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApBNs8kVvneq for ; Mon, 18 Feb 2008 07:40:43 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3DE6028C311 for ; Mon, 18 Feb 2008 07:39:45 -0800 (PST) Received: (qmail invoked by alias); 18 Feb 2008 15:39:43 -0000 Received: from proxy2-nsn.nsn-inter.net (EHLO [217.115.75.230]) [217.115.75.230] by mail.gmx.net (mp018) with SMTP; 18 Feb 2008 16:39:43 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/+ukAZ6lD+nt7oQpBZH0NLJtEEVj28e8uH2NqScg 5ZXN4WVn7GY4P2 Message-ID: <47B9A6BC.4010308@gmx.net> Date: Mon, 18 Feb 2008 17:39:40 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Saverio Niccolini References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> <47B9851C.9040009@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF4D0FD8@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0FD8@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus BoF , Martin Stiemerling Subject: Re: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org For example, one could imagine to develop a mechanism that analyzes the speech characteristic of the caller in order to draw some conclusions about the likelihood of unwanted communication attempt. It is believed that this is not really something we want to work on in RUCUS (and I agree). Ciao Hannes Saverio Niccolini wrote: > Hi, > > >> One thing I got as input was that we should not investigate anything >> relating to the interpretation of RTP. The IAB thought that >> this is very >> much a research issue and I agree with their assessment. >> > > Can you be a bit more precise about "the interpretation of RTP"? > I did not get what you mean by that. > > Cheers, > Saverio > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 07:43:27 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF2828C420; Mon, 18 Feb 2008 07:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua+wjm5zAc5o; Mon, 18 Feb 2008 07:43:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B685B28C40B; Mon, 18 Feb 2008 07:43:26 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A96C28C416 for ; Mon, 18 Feb 2008 07:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgyjXTMLhjJD for ; Mon, 18 Feb 2008 07:43:24 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E124728C35F for ; Mon, 18 Feb 2008 07:43:23 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 8B1A52C00C336 for ; Mon, 18 Feb 2008 16:43:21 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psEd7uiGCisO for ; Mon, 18 Feb 2008 16:43:21 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 70B0E2C000355 for ; Mon, 18 Feb 2008 16:43:16 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 16:43:15 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D1001@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0FF6@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Reading list for BoF Thread-Index: AchyQBxZDSqWpfgaSdKzPXbwMUshrAAABwVAAABwSbAAAIjg8A== References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FED@mx1.office><5FB585F183235B42A9E70095055136FB798528@DEMUEXC012.nsn-intra.net> <5F6519BF2DE0404D99B7C75607FF76FF4D0FF6@mx1.office> From: "Saverio Niccolini" To: "rucus BoF" Subject: Re: [Rucus] Reading list for BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi, = David just submitted a problem statement draft which I think it is interest= ing to read: http://www.ietf.org/internet-drafts/draft-schwartz-rucus-problem-statement-= 01.txt (even if my view is more to see RFC5039 as problem statement document legit= imating RUCUS) where there are some nice points made that are also reflected in: http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam-score-semant= ics-00.txt I see a very important point written there: "Unwanted communication is subj= ective - not objective" This is really true and we can not forget it when talking about RUCUS. A sentence taken from the spam score semantice draft also raises the issue: "Whether a message is spam or not is not a binary proposition, both in terms of identifying it (mechanisms will have false positives and false negatives) and even in judging it (e.g., depending on user preferences)." Saverio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division = Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 = = > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] = > On Behalf Of Saverio Niccolini > Sent: Monday, February 18, 2008 4:30 PM > To: rucus BoF > Subject: Re: [Rucus] Reading list for BoF > = > Hi, > = > there are already some drafts out: > = > -- new version for SPITSTOP draft (-01) > http://tools.ietf.org/html/draft-niccolini-sipping-spitstop-01 > -- new version of the spam score draft (-01) > http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 > -- new draft on spam score semantics (-00) > http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam > -score-semantics-00.txt > -- new draft on SIP spam feedback (-00) > http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 > = > Also an update to the CAPTCHA draft based on recent discussion > will follow, link will be posted as soons as it is submitted. > = > Cheers, > Saverio > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division = > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > = > = > = > > -----Original Message----- > > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] = > > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > > Sent: Monday, February 18, 2008 4:10 PM > > To: Martin Stiemerling; rucus BoF > > Subject: Re: [Rucus] Reading list for BoF > > = > > FYI, we are going to have more documents after the draft = > > submission deadline. = > > = > > = > > = > > > -----Urspr=FCngliche Nachricht----- > > > Von: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] = > > Im Auftrag = > > > von ext Martin Stiemerling > > > Gesendet: Montag, 18. Februar 2008 17:08 > > > An: rucus BoF > > > Betreff: [Rucus] Reading list for BoF > > > = > > > = > > > Hi, > > > = > > > I'm currently trying to get an overview about what has = > > happened in the = > > > field of SPIT mitigation, i.e., editing a useful reading = > > list for the = > > > rucus bof. > > > = > > > Some possible documents to read: > > > - RFC 5039 > > > - SIP Extensions for SPIT identification > > > (draft-niccolini-sipping-feedback-spit-03) > > > - Signaling TO Prevent SPIT (SPITSTOP) Reference Scenario > > > draft-niccolini-sipping-spitstop-01) > > > - Completely Automated Public Turing Test to Tell Computers = > > and Humans = > > > Apart (CAPTCHA) based Robot Challenges for the Session Initiation = > > > Protocol (SIP) > > > (draft-tschofenig-sipping-captcha-00.txt) > > > - A Framework to tackle Spam and Unwanted Communication for = > > > Internet Telephony = > > > (draft-tschofenig-sipping-framework-spit-reduction-02.txt) > > > A Document Format for Expressing Authorization Policies to = > > tackle Spam = > > > and Unwanted Communication for Internet Telephony > > > (draft-tschofenig-sipping-spit-policy-02.txt) > > > - Spam feedback for SIP = > > (draft-niccolini-sipping-spam-feedback-00.txt) > > > - Spam Score for SIP (draft-wing-sipping-spam-score-01.txt) > > > = > > > = > > > Martin > > > = > > > = > > > stiemerling@nw.neclab.eu <=3D=3D NEW ADDRESS > > > = > > > NEC Laboratories Europe - Network Research Division > > > = > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria = > > > Road, London W3 6BL | Registered in England 2832014 = > > > _______________________________________________ > > > Rucus mailing list > > > Rucus@ietf.org > > > http://www.ietf.org/mailman/listinfo/rucus > > > = > > _______________________________________________ > > Rucus mailing list > > Rucus@ietf.org > > http://www.ietf.org/mailman/listinfo/rucus > > = > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > = _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 07:46:07 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A59828C432; Mon, 18 Feb 2008 07:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlcxrAZfV8kR; Mon, 18 Feb 2008 07:46:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65FD428C3DF; Mon, 18 Feb 2008 07:46:02 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6711A28C509 for ; Mon, 18 Feb 2008 07:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgsommPd6fHP for ; Mon, 18 Feb 2008 07:46:00 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 55B9B28C47A for ; Mon, 18 Feb 2008 07:45:52 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EFB972C000355; Mon, 18 Feb 2008 16:45:49 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CFlYoSqYLWv; Mon, 18 Feb 2008 16:45:49 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id DC1E62C00C336; Mon, 18 Feb 2008 16:45:39 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 16:45:39 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D1003@mx1.office> In-Reply-To: <47B9A6BC.4010308@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Scoping question about rucus BoF Thread-Index: AchyRICOSuFLkoYFRFqo3PGpDHUeFwAAJREA References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> <47B9851C.9040009@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF4D0FD8@mx1.office> <47B9A6BC.4010308@gmx.net> From: "Saverio Niccolini" To: Cc: rucus BoF , Martin Stiemerling Subject: Re: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Ok, I agree. I still think that challenging a caller with a CAPTCHA like: "Please dial 3 4 6 to get connected to the callee" (and how to realize this scenario with standard SIP) could be something for RUCUS. Cheers, Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, February 18, 2008 4:40 PM > To: Saverio Niccolini > Cc: Martin Stiemerling; rucus BoF > Subject: Re: [Rucus] Scoping question about rucus BoF > > For example, one could imagine to develop a mechanism that > analyzes the speech characteristic of the caller in order to > draw some conclusions about the likelihood of unwanted > communication attempt. > > It is believed that this is not really something we want to > work on in RUCUS (and I agree). > > Ciao > Hannes > > > > Saverio Niccolini wrote: > > Hi, > > > > > >> One thing I got as input was that we should not > investigate anything > >> relating to the interpretation of RTP. The IAB thought > that this is > >> very much a research issue and I agree with their assessment. > >> > > > > Can you be a bit more precise about "the interpretation of RTP"? > > I did not get what you mean by that. > > > > Cheers, > > Saverio > > > > ============================================================ > > Dr. Saverio Niccolini > > Senior Researcher > > NEC Laboratories Europe, Network Research Division > > Kurfuerstenanlage 36, D-69115 Heidelberg > > Tel. +49 (0)6221 4342-118 > > Fax: +49 (0)6221 4342-155 > > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > > ============================================================ > > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL Registered in England 2832014 > > > > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 07:51:17 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E1728C4E4; Mon, 18 Feb 2008 07:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE9BRMOVa4Vp; Mon, 18 Feb 2008 07:51:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75463A6CD7; Mon, 18 Feb 2008 07:50:53 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6DE3A6CAC for ; Mon, 18 Feb 2008 07:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM0n8plianO5 for ; Mon, 18 Feb 2008 07:50:51 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2DFAE28C35F for ; Mon, 18 Feb 2008 07:50:06 -0800 (PST) Received: (qmail invoked by alias); 18 Feb 2008 15:50:04 -0000 Received: from proxy2-nsn.nsn-inter.net (EHLO [217.115.75.230]) [217.115.75.230] by mail.gmx.net (mp028) with SMTP; 18 Feb 2008 16:50:04 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18BeAJ6+xMBUA3SlaA4JXigrnwryRdYkA2DFnoRDn pEEGK/V2mWq66b Message-ID: <47B9A927.9030509@gmx.net> Date: Mon, 18 Feb 2008 17:49:59 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Saverio Niccolini References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> <47B9851C.9040009@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF4D0FD8@mx1.office> <47B9A6BC.4010308@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF4D1003@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D1003@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus BoF , Martin Stiemerling Subject: Re: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Saverio Niccolini wrote: > Ok, > > I agree. > > I still think that challenging a caller with a CAPTCHA like: > "Please dial 3 4 6 to get connected to the callee" > (and how to realize this scenario with standard SIP) could > be something for RUCUS. > That's something different. Ciao Hannes > Cheers, > Saverio > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, February 18, 2008 4:40 PM >> To: Saverio Niccolini >> Cc: Martin Stiemerling; rucus BoF >> Subject: Re: [Rucus] Scoping question about rucus BoF >> >> For example, one could imagine to develop a mechanism that >> analyzes the speech characteristic of the caller in order to >> draw some conclusions about the likelihood of unwanted >> communication attempt. >> >> It is believed that this is not really something we want to >> work on in RUCUS (and I agree). >> >> Ciao >> Hannes >> >> >> >> Saverio Niccolini wrote: >> >>> Hi, >>> >>> >>> >>>> One thing I got as input was that we should not >>>> >> investigate anything >> >>>> relating to the interpretation of RTP. The IAB thought >>>> >> that this is >> >>>> very much a research issue and I agree with their assessment. >>>> >>>> >>> Can you be a bit more precise about "the interpretation of RTP"? >>> I did not get what you mean by that. >>> >>> Cheers, >>> Saverio >>> >>> ============================================================ >>> Dr. Saverio Niccolini >>> Senior Researcher >>> NEC Laboratories Europe, Network Research Division >>> Kurfuerstenanlage 36, D-69115 Heidelberg >>> Tel. +49 (0)6221 4342-118 >>> Fax: +49 (0)6221 4342-155 >>> e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! >>> ============================================================ >>> NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, >>> London W3 6BL Registered in England 2832014 >>> >>> >> _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 07:58:03 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B6628C416; Mon, 18 Feb 2008 07:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.007 X-Spam-Level: X-Spam-Status: No, score=-0.007 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGxN4FqFDm-u; Mon, 18 Feb 2008 07:58:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7F53A6CCE; Mon, 18 Feb 2008 07:57:35 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E003A68FE for ; Mon, 18 Feb 2008 07:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np97+SMlJlCu for ; Mon, 18 Feb 2008 07:57:34 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 6601228C4CE for ; Mon, 18 Feb 2008 07:56:18 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28044063; Mon, 18 Feb 2008 15:56:15 +0000 In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D1003@mx1.office> References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> <47B9851C.9040009@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF4D0FD8@mx1.office> <47B9A6BC.4010308@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF4D1003@mx1.office> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <4414C0B4-625A-4C75-B5A2-641E333D0267@voxeo.com> From: Dan York Date: Mon, 18 Feb 2008 10:56:13 -0500 To: "Saverio Niccolini" X-Mailer: Apple Mail (2.753) Cc: rucus BoF , Martin Stiemerling Subject: Re: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1029847172==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1029847172== Content-Type: multipart/alternative; boundary=Apple-Mail-79--442809791 --Apple-Mail-79--442809791 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Saverio, I don't think Hannes was indicating that something like a CAPTCHA couldn't be a possible piece of the solution (and indeed it is mentioned in RFC 5039). I don't really see that as "interpreting RTP"... I think of that more in the lines of what Hannes mentioned about "voice stress analysis", etc. Again, though, this is diving down into the weeds of point solutions. We need to take a step back up and look at "the big picture", into which things like a voice CAPTCHA may ultimately fit. Regards, Dan On Feb 18, 2008, at 10:45 AM, Saverio Niccolini wrote: > Ok, > > I agree. > > I still think that challenging a caller with a CAPTCHA like: > "Please dial 3 4 6 to get connected to the callee" > (and how to realize this scenario with standard SIP) could > be something for RUCUS. > > Cheers, > Saverio > -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-79--442809791 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Saverio,

I don't = think Hannes was indicating that something like a CAPTCHA couldn't be a = possible piece of the solution (and indeed it is mentioned in RFC 5039). = =A0 I don't really see that as "interpreting RTP"... I think of that = more in the lines of what Hannes mentioned about "voice stress = analysis", etc.

Again, though, this is = diving down into the weeds of point solutions. =A0We need to take a step = back up and look at "the big picture", into which things like a voice = CAPTCHA may ultimately fit.

Regards,
Dan
=


On = Feb 18, 2008, at 10:45 AM, Saverio Niccolini wrote:

Ok,

I agree.

I still = think that challenging a caller with a CAPTCHA like:
"Please dial 3 4 6 to get connected to the = callee"
(and how to realize this = scenario with standard SIP) could
be something = for RUCUS.

Cheers,

=

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-79--442809791-- --===============1029847172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1029847172==-- From rucus-bounces@ietf.org Mon Feb 18 08:06:13 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54ABC28C38E; Mon, 18 Feb 2008 08:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Bcuj5A6JfaU; Mon, 18 Feb 2008 08:06:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8CB28C3EE; Mon, 18 Feb 2008 08:06:12 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B7928C3B4 for ; Mon, 18 Feb 2008 08:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3HGqjBmhDZy for ; Mon, 18 Feb 2008 08:06:10 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C540928C453 for ; Mon, 18 Feb 2008 08:05:48 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 7167F2C002B48; Mon, 18 Feb 2008 17:05:46 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr7TSam+6dc1; Mon, 18 Feb 2008 17:05:46 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 5ABAA2C000355; Mon, 18 Feb 2008 17:05:31 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 17:05:30 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D1010@mx1.office> In-Reply-To: <4414C0B4-625A-4C75-B5A2-641E333D0267@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Scoping question about rucus BoF Thread-Index: AchyRtPY3u9y9HUDRpK5igQH4AlKzQAAPrsw References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FAE@mx1.office> <47B9851C.9040009@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF4D0FD8@mx1.office> <47B9A6BC.4010308@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF4D1003@mx1.office> <4414C0B4-625A-4C75-B5A2-641E333D0267@voxeo.com> From: "Saverio Niccolini" To: "Dan York" Cc: rucus BoF , Martin Stiemerling Subject: Re: [Rucus] Scoping question about rucus BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dan, I agree, RUCUS is about architecture and CAPTCHA is a punctual solution but I wanted to know the answer since it may impact the architecture. And if we say CAPTCHA can be one solution the architecture shold be thought accordingly. Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: Dan York [mailto:dyork@voxeo.com] > Sent: Monday, February 18, 2008 4:56 PM > To: Saverio Niccolini > Cc: Hannes.Tschofenig@gmx.net; rucus BoF; Martin Stiemerling > Subject: Re: [Rucus] Scoping question about rucus BoF > > Saverio, > > I don't think Hannes was indicating that something like a > CAPTCHA couldn't be a possible piece of the solution (and > indeed it is mentioned in RFC 5039). I don't really see > that as "interpreting RTP"... I think of that more in the > lines of what Hannes mentioned about "voice stress analysis", etc. > > Again, though, this is diving down into the weeds of point > solutions. We need to take a step back up and look at "the > big picture", into which things like a voice CAPTCHA may > ultimately fit. > > Regards, > Dan > > > On Feb 18, 2008, at 10:45 AM, Saverio Niccolini wrote: > > > Ok, > > I agree. > > I still think that challenging a caller with a CAPTCHA like: > "Please dial 3 4 6 to get connected to the callee" > (and how to realize this scenario with standard SIP) could > be something for RUCUS. > > Cheers, > Saverio > > > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 10:09:16 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F70F28C480; Mon, 18 Feb 2008 10:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWmnbJjNtJBY; Mon, 18 Feb 2008 10:09:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC2C28C40B; Mon, 18 Feb 2008 10:09:15 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDD5428C366 for ; Mon, 18 Feb 2008 10:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVIMGPJu41ug for ; Mon, 18 Feb 2008 10:09:14 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id B41A628C2E2 for ; Mon, 18 Feb 2008 10:09:13 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28046422 for rucus@ietf.org; Mon, 18 Feb 2008 18:09:10 +0000 Mime-Version: 1.0 (Apple Message framework v753) To: rucus BoF Message-Id: <882C24AF-F4D2-475E-BA2D-02F965596053@voxeo.com> From: Dan York Date: Mon, 18 Feb 2008 13:09:08 -0500 X-Mailer: Apple Mail (2.753) Subject: [Rucus] Minor quibble with draft-schwartz-rucus-problem-statement-01 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0956021635==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============0956021635== Content-Type: multipart/alternative; boundary=Apple-Mail-82--434834527 --Apple-Mail-82--434834527 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed David, I just had a look at the RUCUS problem statement you put out today: http://tools.ietf.org/html/draft-schwartz-rucus-problem-statement-01 and while I will have some further feedback later, I did just one to make one minor point about something in your introduction: ------ Fortunately (or unfortunately) we have a large body of work already completed in other similar areas such as email and as such the guiding principles of this WG MUST be: What has been done right What has been done wrong What should have been done earlier ------ My issue is your last point. I do NOT think it will be helpful if this group gets mired down in "What should have been done earlier". We are where we are and, IMHO, need to focus on how we move the process forward. (So my feedback would be that this point should be either stricken or clarified for future drafts.) My 2 cents, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-82--434834527 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
David,

I = just had a look at the RUCUS problem statement you put out = today:











= --Apple-Mail-82--434834527-- --===============0956021635== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============0956021635==-- From rucus-bounces@ietf.org Mon Feb 18 10:27:45 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FFD33A68BE; Mon, 18 Feb 2008 10:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.221 X-Spam-Level: ** X-Spam-Status: No, score=2.221 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPLWNnyxfidR; Mon, 18 Feb 2008 10:27:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F7928C3DE; Mon, 18 Feb 2008 10:27:42 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5587228C400 for ; Mon, 18 Feb 2008 10:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+PnF8THEQKH for ; Mon, 18 Feb 2008 10:27:39 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by core3.amsl.com (Postfix) with ESMTP id B18F328C3DE for ; Mon, 18 Feb 2008 10:27:38 -0800 (PST) Received: from [172.16.4.100] (barak.cellcom.co.il [212.150.188.226]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1JRAi80ggB-0006iN; Mon, 18 Feb 2008 19:27:32 +0100 References: <882C24AF-F4D2-475E-BA2D-02F965596053@voxeo.com> Message-Id: <0E1E1D42-17E7-46FC-B70C-FFFF77F5AE67@xconnect.net> From: David Schwartz To: Dan York In-Reply-To: <882C24AF-F4D2-475E-BA2D-02F965596053@voxeo.com> X-Mailer: iPhone Mail (3A109a) Mime-Version: 1.0 (iPhone Mail 3A109a) Date: Mon, 18 Feb 2008 20:27:20 +0200 X-Provags-ID: V01U2FsdGVkX18kIkGfBjzi2kmpB87vlvCg2O5d20k0XUbQ1ye Lig+rNebINrmRDDgPBpSJkfD0S8M0c+rHB7TiCkB6p24QEom5p 9lyC0vxkgVH8mjlZCMxgQ== Cc: rucus BoF Subject: Re: [Rucus] Minor quibble with draft-schwartz-rucus-problem-statement-01 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0169016320==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============0169016320== Content-Type: multipart/alternative; boundary=Apple-Mail-1--433741706 --Apple-Mail-1--433741706 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi dan My goal is not to rehash or "fix" anything. I merely asked myself "what if I was defining email standards today, knowing what I know now? What would I do the same and what would I have implemented earlier?" This is not an attempt to second guess - only to learn from other similar technologies. D On Feb 18, 2008, at 8:09 PM, Dan York wrote: > David, > > I just had a look at the RUCUS problem statement you put out today: > > http://tools.ietf.org/html/draft-schwartz-rucus-problem- > statement-01 > > and while I will have some further feedback later, I did just one to > make one minor point about something in your introduction: > ------ > Fortunately (or unfortunately) we have a large body of work already > completed in other similar areas such as email and as such the > guiding principles of this WG MUST be: > > What has been done right > > What has been done wrong > > What should have been done earlier > ------ > > My issue is your last point. I do NOT think it will be helpful if > this group gets mired down in "What should have been done earlier". > We are where we are and, IMHO, need to focus on how we move the > process forward. (So my feedback would be that this point should > be either stricken or clarified for future drafts.) > > My 2 cents, > Dan > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus --Apple-Mail-1--433741706 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
Hi dan

My goal is not to rehash = or "fix" anything.  I merely asked myself "what if I was defining = email standards today, knowing what I know now? What would I do the same = and what would I have implemented earlier?"

This is not an attempt to = second guess - only to learn from other similar = technologies.

D

On Feb 18, 2008, at 8:09 = PM, Dan York <dyork@voxeo.com> = wrote:

David,

I = just had a look at the RUCUS problem statement you put out = today:


and = while I will have some further feedback later, I did just one to make = one minor point about something in your = introduction:
------
   Fortunately (or = unfortunately) we have a large body of work = already
   completed in other similar areas such as = email and as such the
   guiding principles of this = WG MUST be:

   What has been = done right

   What has been = done wrong

   What should = have been done earlier
------

My issue is your last = point.  I do NOT think it will be helpful if this group gets mired = down in "What should have been done earlier".  
We are = where we are and, IMHO, need to focus on how we move the process = forward.   (So my feedback would be that this point should be = either stricken or clarified for future drafts.)

My 2 = cents,
Dan

-- 
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     dyork@voxeo.com
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com

Bring your web applications to the phone.


= ______________________________________________________________________
= This email has been scanned by the MessageLabs Email Security = System.
For more information please visit http://www.messagelabs.com/email=
= ______________________________________________________________________
=
_______________________________________________
Rucus mailing list
Rucus@ietf.org
http://www.ietf.org/ma= ilman/listinfo/rucus
= --Apple-Mail-1--433741706-- --===============0169016320== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============0169016320==-- From rucus-bounces@ietf.org Mon Feb 18 10:40:20 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1198428C370; Mon, 18 Feb 2008 10:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.043 X-Spam-Level: X-Spam-Status: No, score=0.043 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-kQZ41WxKRV; Mon, 18 Feb 2008 10:40:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCF728C3AB; Mon, 18 Feb 2008 10:40:18 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90DF23A6785 for ; Mon, 18 Feb 2008 10:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWiyatwh6CiF for ; Mon, 18 Feb 2008 10:40:16 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 92D2F3A6B73 for ; Mon, 18 Feb 2008 10:40:16 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28046940; Mon, 18 Feb 2008 18:40:13 +0000 In-Reply-To: <0E1E1D42-17E7-46FC-B70C-FFFF77F5AE67@xconnect.net> References: <882C24AF-F4D2-475E-BA2D-02F965596053@voxeo.com> <0E1E1D42-17E7-46FC-B70C-FFFF77F5AE67@xconnect.net> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Dan York Date: Mon, 18 Feb 2008 13:40:11 -0500 To: David Schwartz X-Mailer: Apple Mail (2.753) Cc: rucus BoF Subject: Re: [Rucus] Minor quibble with draft-schwartz-rucus-problem-statement-01 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1596677778==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1596677778== Content-Type: multipart/alternative; boundary=Apple-Mail-83--432971901 --Apple-Mail-83--432971901 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed David, On Feb 18, 2008, at 1:27 PM, David Schwartz wrote: > > My goal is not to rehash or "fix" anything. I merely asked myself > "what if I was defining email standards today, knowing what I know > now? What would I do the same and what would I have implemented > earlier?" > > This is not an attempt to second guess - only to learn from other > similar technologies. Okay, we're on the same page! (Whew!) Can I then suggest that perhaps that instead of: What should have been done earlier your draft could read: What we can learn from other similar technologies (and what might have been done earlier in those cases) Or something like that? Thanks for clarifying, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-83--432971901 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 David,

On Feb 18, 2008, at 1:27 PM, David Schwartz = wrote:

My goal is not = to rehash or "fix" anything.=A0 I merely asked myself "what if I was = defining email standards today, knowing what I know now? What would I do = the same and what would I have implemented earlier?"

This is not an attempt to = second guess - only to learn from other similar = technologies.

Okay, we're on the same page! = =A0(Whew!)

Can= I then suggest that perhaps that instead of:

=A0=A0 =A0 What should = have been done earlier

your draft could = read:

=A0=A0 = =A0 =A0What we can learn from other similar technologies (and what might = have been done earlier in those cases)

Or something like = that?

Thanks = for clarifying,
Dan

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-83--432971901-- --===============1596677778== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1596677778==-- From rucus-bounces@ietf.org Mon Feb 18 12:55:15 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03A2B28C5CC; Mon, 18 Feb 2008 12:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPWGfEqqRfXm; Mon, 18 Feb 2008 12:55:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7363A6D98; Mon, 18 Feb 2008 12:53:41 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC72C3A6D96 for ; Mon, 18 Feb 2008 12:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8uMAn6mEpOb for ; Mon, 18 Feb 2008 12:53:39 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id ADE733A6DA4 for ; Mon, 18 Feb 2008 12:51:09 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id C103C4C3ED; Mon, 18 Feb 2008 21:51:05 +0100 (CET) Date: Mon, 18 Feb 2008 21:51:05 +0100 From: Otmar Lendl To: Dan Wing Message-ID: <20080218205105.GT13520@bofh.priv.at> References: <20080215161045.GC13520@bofh.priv.at> <124401c87003$ea9930e0$c4f0200a@cisco.com> <20080215194050.GD13520@bofh.priv.at> <139b01c8700e$876e1250$c4f0200a@cisco.com> <20080215214731.GE13520@bofh.priv.at> <01a101c8701e$5f2c07b0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <01a101c8701e$5f2c07b0$c4f0200a@cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: rucus@ietf.org, 'Signaling TO Prevent SPIT' Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org (I'm trying to keep this short) On 2008/02/15 23:02, Dan Wing wrote: > > which actually bolsters my claim that we > > really need to be clear whether we're building a solution for > > PSTN replacement services or just for fancy alternative services. > > I'm sorry, but I am unable to understand the distinction you > desire, even though we have exchanged several emails on this. Quick summary: PSTN-like systems have special regulatory status and are unique in a sense that they are the default pathway for a certain type of communication (e.g. voice, email). You can't "opt out of the PSTN and its rules" if you still want to be reachable by the world via the telephone. Anybody building something new can define the rules for using this new setup and they might be different to what others use who build similar new communication systems. Thus there is competition between such system, e.g. if I don't like the way company Foo is running and policing their IM systen, then I (and my friends) can switch to Bar's system. I maintain that this distiction is very relevant to the design of SPIT-avoidance systems. /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 12:58:54 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C103A6C5C; Mon, 18 Feb 2008 12:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+PkwUo8xn2X; Mon, 18 Feb 2008 12:58:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B4528C549; Mon, 18 Feb 2008 12:58:01 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9303A6D61 for ; Mon, 18 Feb 2008 12:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoTtt6zIeSJ2 for ; Mon, 18 Feb 2008 12:57:59 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 47FB728C55D for ; Mon, 18 Feb 2008 12:55:34 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 134874C3ED; Mon, 18 Feb 2008 21:55:31 +0100 (CET) Date: Mon, 18 Feb 2008 21:55:31 +0100 From: Otmar Lendl To: Saverio Niccolini Message-ID: <20080218205531.GU13520@bofh.priv.at> References: <20080215214731.GE13520@bofh.priv.at> <5F6519BF2DE0404D99B7C75607FF76FF4D0F01@mx1.office> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0F01@mx1.office> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: rucus@ietf.org, Signaling TO Prevent SPIT Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/17 00:02, Saverio Niccolini wrote: > Hi again, > > > So yes, I agree with your example (though I don't know what a > > fancy header would help), which actually bolsters my claim > > that we really need to be clear whether we're building a > > solution for PSTN replacement services or just for fancy > > alternative services. > > ok, you want to focus on "a: we are building a solution > that assumes the same rules that PSTN has nowadays" > > It is fine with me as well, I just think it is going to > be more complicated to get consensus on a solution if we > assume too many restrictions, but I am willing to work on > this I'm not particulary invested in the question which setup RUCUS should focus on. What I really care about is a common understanding on the basic communication ecosystem for which we try to develop a solution. (IMHO that's missing in speermint, which might be the most important reason that speermint hasn't produced any worthwhile output so far.) /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 12:59:06 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E583A6819; Mon, 18 Feb 2008 12:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-1.609, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72h-UeHo5kIE; Mon, 18 Feb 2008 12:59:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509BF3A6875; Mon, 18 Feb 2008 12:59:02 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E703A6837 for ; Mon, 18 Feb 2008 12:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWhYd39PwYgR for ; Mon, 18 Feb 2008 12:58:59 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8B6BB3A6D81 for ; Mon, 18 Feb 2008 12:58:50 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 18 Feb 2008 12:58:48 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1IKwmJF025882; Mon, 18 Feb 2008 12:58:48 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1IKwkuL021793; Mon, 18 Feb 2008 20:58:46 GMT From: "Dan Wing" To: "'Otmar Lendl'" References: <20080215161045.GC13520@bofh.priv.at> <124401c87003$ea9930e0$c4f0200a@cisco.com> <20080215194050.GD13520@bofh.priv.at> <139b01c8700e$876e1250$c4f0200a@cisco.com> <20080215214731.GE13520@bofh.priv.at> <01a101c8701e$5f2c07b0$c4f0200a@cisco.com> <20080218205105.GT13520@bofh.priv.at> Date: Mon, 18 Feb 2008 12:58:46 -0800 Message-ID: <02f901c87271$0dad47f0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080218205105.GT13520@bofh.priv.at> Thread-Index: AchycBXvxZ5QiY+lS06dEBmc7BfIJgAAIrpg Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: rucus@ietf.org, 'Signaling TO Prevent SPIT' Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > (I'm trying to keep this short) > > On 2008/02/15 23:02, Dan Wing wrote: > > > which actually bolsters my claim that we > > > really need to be clear whether we're building a solution for > > > PSTN replacement services or just for fancy alternative services. > > > > I'm sorry, but I am unable to understand the distinction you > > desire, even though we have exchanged several emails on this. > > Quick summary: > > PSTN-like systems have special regulatory status and are unique in > a sense that they are the default pathway for a certain type of > communication (e.g. voice, email). You can't "opt out of the PSTN and > its rules" if you still want to be reachable by the world via the > telephone. > > Anybody building something new can define the rules for using this new > setup and they might be different to what others use who build > similar new communication systems. Thus there is competition between > such system, e.g. if I don't like the way company Foo is running and > policing their IM systen, then I (and my friends) can switch to Bar's > system. > > I maintain that this distiction is very relevant to the design of > SPIT-avoidance systems. If I create an identity on, say, gmail.com, and it is my identity on publicly-facing documents, presentations I give, columns I write, email that I post to mailing lists, hand out dozens of business cards with my email address, etc., I can't just "pack up my bags" (so to speak) and jump to a different email provider. I expect the same would be true of my identity on Skype, IM networks (Yahoo, Hotmail, MSN, etc.). It's true I could pack up and leave those, but packing up and leaving those networks is not trivial or easy. I would need to get re-added on all of my friend's white lists (which is the only viable mechanism on those networks for me and for my friends to avoid getting spammed by advertising when on those networks). -d _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 13:05:23 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D073A6891; Mon, 18 Feb 2008 13:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAYlG-z5wHC9; Mon, 18 Feb 2008 13:05:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A2E3A689E; Mon, 18 Feb 2008 13:05:22 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6473A689E for ; Mon, 18 Feb 2008 13:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqBURFKfb7fn for ; Mon, 18 Feb 2008 13:05:20 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id AF0363A6891 for ; Mon, 18 Feb 2008 13:05:20 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id A5E6B4C3ED; Mon, 18 Feb 2008 22:05:15 +0100 (CET) Date: Mon, 18 Feb 2008 22:05:15 +0100 From: Otmar Lendl To: Saverio Niccolini Message-ID: <20080218210515.GV13520@bofh.priv.at> References: <20080215161045.GC13520@bofh.priv.at> <5F6519BF2DE0404D99B7C75607FF76FF4D0F00@mx1.office> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D0F00@mx1.office> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: rucus@ietf.org, spitstop@listserv.netlab.nec.de Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/16 23:02, Saverio Niccolini wrote: > > My point in saying that was focus on technical work needs assuming > that SPIT communications are between trusted entities (to simplify > the scenario and reach faster an agreement on work to be done). Actually, this is one point I would ask the email/SPAM people: What percentage of the SPAM problem is due to the fact that email is received from non-trusted entities? Or a bit watered down: What percentage of the SPAM problem is due to the fact that email is received from unknown entities? I have this nagging feeling that herein lies the crux of the SPAM problem: SMTP servers need to accept connections from any host in the Internet. If this is true (as of now, this is my gut feeling, we'd have to confirm this), then focusing on a case which excludes the basic reason for the problem in the first place, sounds non-productive. > > > In the pure bi-lateral trusted case you do the same. If you > > know that this is a likely spit-call, then don't even pass it > > to your peer. > > You are missing one point here: in the case you want to address > "a", you can not simply suppress communications (not even in a > single domain) because this is not legal, this why you may > need to have SPIT indications (scores and user feedbacks) and > apply policies (that the user needs to agree with). Ah sorry, I was still thinking within your "let's consider case b)" first frame. /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 13:11:24 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC7228C3A0; Mon, 18 Feb 2008 13:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZQ0TeDhWP40; Mon, 18 Feb 2008 13:11:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9693A6D6C; Mon, 18 Feb 2008 13:11:23 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368C93A6D6E for ; Mon, 18 Feb 2008 13:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUQ3Zvwg9GGM for ; Mon, 18 Feb 2008 13:11:21 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id F3BC33A689E for ; Mon, 18 Feb 2008 13:11:20 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 3E6E44C3ED; Mon, 18 Feb 2008 22:11:17 +0100 (CET) Date: Mon, 18 Feb 2008 22:11:17 +0100 From: Otmar Lendl To: rucus@ietf.org Message-ID: <20080218211117.GW13520@bofh.priv.at> References: <47B9A5C0.5080704@gmx.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <47B9A5C0.5080704@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [Rucus] [Fwd: I-D Action:draft-schwartz-rucus-problem-statement-01.txt] X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/18 16:02, Hannes Tschofenig wrote: > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-schwartz-rucus-problem-statement-01.txt > Two quick comments: I'm a bit stumped that "Misrepresentation" lists "Telemarketing" as an example. Based on my (rare) experiences with cold-call telemarketing in the real world I'd rate "Telemarketing" as RUCUS without any "Misrepresentation" as to who is calling. I'm missing DoS (intentional and by software error) as category for "unwanted communication". /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 13:35:44 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C1728C45A; Mon, 18 Feb 2008 13:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGXCb8zJTd94; Mon, 18 Feb 2008 13:35:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66B7528C27E; Mon, 18 Feb 2008 13:35:43 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2272D3A6876 for ; Mon, 18 Feb 2008 13:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS0HKdCvt-aS for ; Mon, 18 Feb 2008 13:35:39 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 0E0C828C462 for ; Mon, 18 Feb 2008 13:35:13 -0800 (PST) Received: from [10.0.1.198] (bzq-219-131-200.static.bezeqint.net [62.219.131.200]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1JRDdl07Vd-00051b; Mon, 18 Feb 2008 22:35:09 +0100 Message-Id: <95F89869-D234-4D26-AEE8-DBDE6D4ABEF0@xconnect.net> From: David Schwartz To: Otmar Lendl In-Reply-To: <20080218211117.GW13520@bofh.priv.at> Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 18 Feb 2008 23:35:07 +0200 References: <47B9A5C0.5080704@gmx.net> <20080218211117.GW13520@bofh.priv.at> X-Mailer: Apple Mail (2.915) X-Provags-ID: V01U2FsdGVkX19RINIUC/7mamL2CyQmNAIUsqE6PbTMuHVyxQx apYUPjOwJRCKYI8RbxYWH23Ydw/5uSUw0zCEbHJuwrA2rZWLLa earB6HdRm6VHqoDeHb1pw== Cc: rucus@ietf.org Subject: Re: [Rucus] [Fwd: I-D Action:draft-schwartz-rucus-problem-statement-01.txt] X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On Feb 18, 2008, at 11:11 PM, Otmar Lendl wrote: > On 2008/02/18 16:02, Hannes Tschofenig > wrote: >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-schwartz-rucus-problem-statement-01.txt >> > > Two quick comments: > > I'm a bit stumped that "Misrepresentation" lists "Telemarketing" as an > example. Based on my (rare) experiences with cold-call telemarketing > in the real world I'd rate "Telemarketing" as RUCUS without any > "Misrepresentation" as to who is calling. DS: This is a good catch. Telemarketing actually belongs to the "Lack- of-policy" group where there is no malice only annoyance. > > > I'm missing DoS (intentional and by software error) as category for > "unwanted communication". > DS: I didn't want to turn this into a general "VoIP Threat document" so I tried to focus on end-to-end communication threats (including number harvesting which leads to a call). (The "underprivileged" remained in by accident as this too is more of a system threat than an "unwanted communication" one.) > /ol > -- > -=- Otmar Lendl -- ol@bofh.priv.at -=- > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 13:38:08 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C149A3A6D7A; Mon, 18 Feb 2008 13:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwTpUTkt-jze; Mon, 18 Feb 2008 13:38:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09FF33A691B; Mon, 18 Feb 2008 13:38:08 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F933A6918 for ; Mon, 18 Feb 2008 13:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1FdYMVQKGV9 for ; Mon, 18 Feb 2008 13:38:06 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 1B0C93A68A4 for ; Mon, 18 Feb 2008 13:38:05 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 9386C4C3ED; Mon, 18 Feb 2008 22:38:02 +0100 (CET) Date: Mon, 18 Feb 2008 22:38:02 +0100 From: Otmar Lendl To: Dan Wing Message-ID: <20080218213802.GX13520@bofh.priv.at> References: <20080215161045.GC13520@bofh.priv.at> <124401c87003$ea9930e0$c4f0200a@cisco.com> <20080215194050.GD13520@bofh.priv.at> <139b01c8700e$876e1250$c4f0200a@cisco.com> <20080215214731.GE13520@bofh.priv.at> <01a101c8701e$5f2c07b0$c4f0200a@cisco.com> <20080218205105.GT13520@bofh.priv.at> <02f901c87271$0dad47f0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <02f901c87271$0dad47f0$c4f0200a@cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: rucus@ietf.org, 'Signaling TO Prevent SPIT' Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/18 21:02, Dan Wing wrote: > > If I create an identity on, say, gmail.com, and it is my identity on > publicly-facing documents, presentations I give, columns I write, > email that I post to mailing lists, hand out dozens of business > cards with my email address, etc., I can't just "pack up my bags" > (so to speak) and jump to a different email provider. Well, the "official solutions" to that problem in email and telephony are "get your own domain" and "number portability". Once you de-couple your address from your provider, packing the bags and moving is no issue. > I expect the same would be true of my identity on Skype, IM networks > (Yahoo, Hotmail, MSN, etc.). It's true I could pack up and leave > those, but packing up and leaving those networks is not trivial > or easy. I would need to get re-added on all of my friend's white > lists (which is the only viable mechanism on those networks for > me and for my friends to avoid getting spammed by advertising when > on those networks). ... which brings us to a crucial question: Can the "white list" approach work in a a PSTN-replacement service? ("work" in that context needs to be technical, from a UI perspective, and from a service expectation point of view.) /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 13:53:14 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3AE33A6D80; Mon, 18 Feb 2008 13:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=-1.883, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lV4f09qTAgXR; Mon, 18 Feb 2008 13:53:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28A43A691B; Mon, 18 Feb 2008 13:53:13 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A343A6950 for ; Mon, 18 Feb 2008 13:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR7y1SIpdnIo for ; Mon, 18 Feb 2008 13:53:10 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1B1743A691B for ; Mon, 18 Feb 2008 13:53:10 -0800 (PST) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-3.cisco.com with ESMTP; 18 Feb 2008 13:53:08 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id m1ILr7TZ028782; Mon, 18 Feb 2008 13:53:07 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1ILr6vn018582; Mon, 18 Feb 2008 21:53:06 GMT From: "Dan Wing" To: "'Otmar Lendl'" References: <20080215161045.GC13520@bofh.priv.at> <124401c87003$ea9930e0$c4f0200a@cisco.com> <20080215194050.GD13520@bofh.priv.at> <139b01c8700e$876e1250$c4f0200a@cisco.com> <20080215214731.GE13520@bofh.priv.at> <01a101c8701e$5f2c07b0$c4f0200a@cisco.com> <20080218205105.GT13520@bofh.priv.at> <02f901c87271$0dad47f0$c4f0200a@cisco.com> <20080218213802.GX13520@bofh.priv.at> Date: Mon, 18 Feb 2008 13:53:06 -0800 Message-ID: <038c01c87278$a54b32f0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080218213802.GX13520@bofh.priv.at> Thread-Index: AchydthCERDAhNwBRxS/ogTxgjjGowAAMyxw Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); Cc: rucus@ietf.org, 'Signaling TO Prevent SPIT' Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > > If I create an identity on, say, gmail.com, and it is my identity on > > publicly-facing documents, presentations I give, columns I write, > > email that I post to mailing lists, hand out dozens of business > > cards with my email address, etc., I can't just "pack up my bags" > > (so to speak) and jump to a different email provider. > > Well, the "official solutions" to that problem in email and telephony > are "get your own domain" and "number portability". > > Once you de-couple your address from your provider, packing the > bags and moving is no issue. Ok. > > I expect the same would be true of my identity on Skype, IM > > networks > > (Yahoo, Hotmail, MSN, etc.). It's true I could pack up and leave > > those, but packing up and leaving those networks is not trivial > > or easy. I would need to get re-added on all of my friend's white > > lists (which is the only viable mechanism on those networks for > > me and for my friends to avoid getting spammed by advertising when > > on those networks). > > ... which brings us to a crucial question: > > Can the "white list" approach work in a a PSTN-replacement service? > > ("work" in that context needs to be technical, from a UI perspective, > and from a service expectation point of view.) White lists only work if there is a separate, out-of-band mechanism to communicate to someone before you are on their white list. For example, with today's IM systems, you usually email, SMS, or call your friend and ask to be placed on their whitelist. Some IM systems allow you to send a request, through the IM system itself, to be added to the receiver's white list ("become a friend"); I presume those IM systems have some sort of accounting and some sort of limits on the number of people you can invite, otherwise a spammer would simply invite everybody on the entire IM system, hoping that a few people would accept adding the spammer to the whitelist, and now the spammer is able to send spam to those people. Without a mechanism to add someone to a whitelist, I don't see whitelists working. That mechanism does not necessarily need to be built into the protocol itself; afterall, emailing or SMS'ing or calling my friend to ask he add me to his whitelist is not part of any IM system. So, if we had a SIP system with a whitelist, how would you ask to be added to a whitelist? Send an email?? And clearly, while whitelists work well for individuals, they are less valuable for for companies. Consider for example a mail- order company such as Sears. They want to accept calls from potential customers (which are not yet on their whitelist) but they would naturally prefer to avoid dealing with incoming calls from spammers. Identifying a spammer versus a potential customer is difficult, of course. My own employer, I would imagine, has well-known spammers that are also legitimate customers (that is, who have purchased routers or ethernet switches) and all legitimate customers should be able to contact technical support. -d _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 14:09:00 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A713A6D97; Mon, 18 Feb 2008 14:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P9oK3NIZBpA; Mon, 18 Feb 2008 14:08:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFE63A6D7F; Mon, 18 Feb 2008 14:04:41 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E743A6D7A for ; Mon, 18 Feb 2008 14:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBslsi+adiB8 for ; Mon, 18 Feb 2008 14:04:39 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id EF9073A6D9B for ; Mon, 18 Feb 2008 14:04:22 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28051381 for rucus@ietf.org; Mon, 18 Feb 2008 22:04:19 +0000 Mime-Version: 1.0 (Apple Message framework v753) To: rucus BoF Message-Id: <865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com> References: <20080218201501.60A6A28C54D@core3.amsl.com> From: Dan York Date: Mon, 18 Feb 2008 17:04:17 -0500 X-Mailer: Apple Mail (2.753) Subject: [Rucus] SIP scenarios similar to SPIT - Fwd: I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2094405353==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============2094405353== Content-Type: multipart/alternative; boundary=Apple-Mail-93--420725676 --Apple-Mail-93--420725676 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed RUCUS members, FYI, based on the feedback of a number of folks, I did submit a new version of this document today. It is still tagged -00 because this time I added the workgroup name to the file name (which I missed doing when I originally posted it as draft-york-spit-similarity- scenarios-00.txt): http://www.ietf.org/internet-drafts/draft-york-sipping-spit- similarity-scenarios-00.txt It has, however, changed slightly from the first draft as I incorporated a few more scenarios suggested by people and also broke out the inbound scenarios a bit more. Feedback is of course definitely welcome. As we talk about potential architectures to address SPIT, my intent really is to highlight the fact that there are scenarios where legitimate SIP traffic might easily be mistaken for one form of SPIT. Regards, Dan Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: February 18, 2008 3:15:01 PM EST > To: i-d-announce@ietf.org > Subject: I-D Action:draft-york-sipping-spit-similarity- > scenarios-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SIP Usage Scenarios Similar to SPIT > Author(s) : D. York > Filename : draft-york-sipping-spit-similarity-scenarios-00.txt > Pages : 11 > Date : 2008-02-18 > > This document outlines scenarios in which legitimate SIP traffic may > appear similar to traffic associated with voice spam, also known as > "SPIT" or "Spam for Internet Telephony. This document is created to > provide input into the current discussions about how best to address > the issue of SPIT. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-york-sipping-spit- > similarity-scenarios-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-york-sipping-spit-similarity-scenarios-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-york-sipping-spit-similarity- > scenarios-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2008-02-18120051.I-D\@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > http://www.ietf.org/mailman/listinfo/i-d-announce -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-93--420725676 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 RUCUS members,

FYI, = based on the feedback of a number of folks, I did submit a new version = of this document today. It is still tagged -00 because this time I added = the workgroup name to the file name (which I missed doing when I = originally posted it as = draft-york-spit-similarity-scenarios-00.txt):


It has, however, changed = slightly from the first draft as I incorporated a few more scenarios = suggested by people and also broke out the inbound scenarios a bit = more.

Feedback= is of course definitely welcome. =A0As we talk about potential = architectures to address SPIT, my intent really is to highlight the fact = that there are scenarios where legitimate SIP traffic might easily be = mistaken for one form of SPIT.

Regards,
Dan

Begin forwarded message:

Date: February 18, 2008 3:15:01 PM = EST
To: i-d-announce@ietf.org
Subject: = I-D = Action:draft-york-sipping-spit-similarity-scenarios-00.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

Title =A0 =A0 =A0 =A0 =A0 : SIP Usage = Scenarios Similar to SPIT
Author(s) = =A0 =A0 =A0 : D. = York
Filename=A0 =A0 =A0 =A0 : = draft-york-sipping-spit-similarity-scenarios-00.txt
Pages =A0 =A0 =A0 =A0 =A0 : = 11
Date=A0 =A0 =A0 =A0 =A0 =A0 : = 2008-02-18

This document outlines scenarios in which legitimate = SIP traffic may
appear similar to traffic = associated with voice spam, also known as
"SPIT" = or "Spam for Internet Telephony.=A0 = This document is created to
provide input = into the current discussions about how best to address
the issue of SPIT.

A URL for = this Internet-Draft is:

To remove = yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then
"get = draft-york-sipping-spit-similarity-scenarios-00.txt".

A list = of Internet-Drafts directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-york-sipping-spit-similarity-scenarios-00.txt".

NOTE: = =A0 The mail server at = ietf.org can return the document in
= MIME-encoded form by using the "mpack" utility.=A0 To use this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain
Content-ID: = <2008-02-18120051.I-D\@ietf.org>

I-D-Announce mailing list
=

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=
= --Apple-Mail-93--420725676-- --===============2094405353== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============2094405353==-- From rucus-bounces@ietf.org Mon Feb 18 15:46:32 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1BE3A67AE; Mon, 18 Feb 2008 15:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohzIK0P1totR; Mon, 18 Feb 2008 15:46:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471243A68FB; Mon, 18 Feb 2008 15:46:27 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57723A68C5 for ; Mon, 18 Feb 2008 15:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CgGPWCLa+wY for ; Mon, 18 Feb 2008 15:46:24 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 72FDC3A69A7 for ; Mon, 18 Feb 2008 15:46:20 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28052919; Mon, 18 Feb 2008 23:46:16 +0000 In-Reply-To: <95F89869-D234-4D26-AEE8-DBDE6D4ABEF0@xconnect.net> References: <47B9A5C0.5080704@gmx.net> <20080218211117.GW13520@bofh.priv.at> <95F89869-D234-4D26-AEE8-DBDE6D4ABEF0@xconnect.net> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Dan York Date: Mon, 18 Feb 2008 18:46:14 -0500 To: David Schwartz X-Mailer: Apple Mail (2.753) Cc: rucus@ietf.org Subject: Re: [Rucus] [Fwd: I-D Action:draft-schwartz-rucus-problem-statement-01.txt] X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0224542340==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============0224542340== Content-Type: multipart/alternative; boundary=Apple-Mail-101--414608394 --Apple-Mail-101--414608394 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 18, 2008, at 4:35 PM, David Schwartz wrote: >> I'm a bit stumped that "Misrepresentation" lists "Telemarketing" >> as an >> example. Based on my (rare) experiences with cold-call telemarketing >> in the real world I'd rate "Telemarketing" as RUCUS without any >> "Misrepresentation" as to who is calling. > > DS: This is a good catch. Telemarketing actually belongs to the "Lack- > of-policy" group where there is no malice only annoyance. DY> Yes, this was one of my points, too, so I agree it needs to move. >> I'm missing DoS (intentional and by software error) as category for >> "unwanted communication". >> > > DS: I didn't want to turn this into a general "VoIP Threat document" > so I tried to focus on end-to-end communication threats (including > number harvesting which leads to a call). (The "underprivileged" > remained in by accident as this too is more of a system threat than an > "unwanted communication" one.) DY> I completely agree with this statement. We need to scope this group appropriately or else we will never accomplish anything. We can't address all the VoIP security threats, but we can take a look at a subset related to unwanted communication. DY> I'll follow up with more comments on the overall document soon. Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-101--414608394 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Feb 18, 2008, at 4:35 PM, David Schwartz = wrote:

I'm a bit stumped that = "Misrepresentation" lists "Telemarketing" as an
example. Based on my (rare) experiences with = cold-call telemarketing
in the real = world I'd rate "Telemarketing" as RUCUS without any
"Misrepresentation" as to who is calling.
=

DS: This is a good catch. Telemarketing actually = belongs to the "Lack-=A0

DY> Yes, this was one of my = points, too, so I agree it needs to move.

I'm missing DoS (intentional = and by software error) as category for
"unwanted communication".


DS: I = didn't want to turn this into a general "VoIP Threat document" =A0
so I = tried to focus on end-to-end communication threats (including =A0
number = harvesting which leads to a call). (The "underprivileged" =A0
remained = in by accident as this too is more of a system threat than an =A0

DY> = I completely agree with this statement. =A0We need to scope this group = appropriately or else we will never accomplish anything. =A0We can't = address =A0all the VoIP security threats, but we can take a look at a = subset related to unwanted communication.

DY> I'll follow up with = more comments on the overall document soon.

Regards,
Dan
=

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.




= --Apple-Mail-101--414608394-- --===============0224542340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============0224542340==-- From rucus-bounces@ietf.org Mon Feb 18 16:14:30 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738FB3A6AC8; Mon, 18 Feb 2008 16:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.763 X-Spam-Level: X-Spam-Status: No, score=0.763 tagged_above=-999 required=5 tests=[AWL=-1.096, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eQfEtawF5-n; Mon, 18 Feb 2008 16:14:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228403A6A77; Mon, 18 Feb 2008 16:14:29 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DC53A69D7 for ; Mon, 18 Feb 2008 16:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl2heQ0UMc+8 for ; Mon, 18 Feb 2008 16:14:26 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 142CD3A6857 for ; Mon, 18 Feb 2008 16:14:25 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28053184 for rucus@ietf.org; Tue, 19 Feb 2008 00:14:22 +0000 Mime-Version: 1.0 (Apple Message framework v753) To: rucus BoF Message-Id: <9ADADBC8-ECBC-4B39-B6B6-A616B0D42ACA@voxeo.com> From: Dan York Date: Mon, 18 Feb 2008 19:14:20 -0500 X-Mailer: Apple Mail (2.753) Subject: [Rucus] Review of David's RUCUS Problem Statement X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0292441953==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============0292441953== Content-Type: multipart/alternative; boundary=Apple-Mail-102--412922759 --Apple-Mail-102--412922759 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Okay, so here are some comments about David's "problem statement" as shown here: http://www.ietf.org/internet-drafts/draft-schwartz-rucus-problem- statement-01.txt First, I do think documents like this are useful to help us refine what it is we want to talk about at our meeting in Philadelphia, so thanks, David, for taking the time to write this. Stepping through the document: 1. Introduction =========== A couple of comments: First, I don't know that I would characterize the attacks mentioned in RFC5039 only as "misrepresentation". I view it as broader than that, but then I guess I have some issues with how you have characterized it (but more on that in a moment). Second, you indicate that this document and by extension this WG/BOF is focusing on "all types of 'unwanted' commmunications". Perhaps here is where we need to discuss drawing lines a bit further. When we think of "SPIT" (or whatever you want to call it), who is the communication attacking? The human using the device? Or the system? Or both? When *I* think of "SPIT", I am thinking of unwanted calls that I (or the voicemail system or other apps receiving calls on my behalf) receive. I am not necessarily thinking of system probes (such as perhaps what you define as Data Mining). Third, I've already commented on my view of "What should have been done earlier". 2. Unwanted Communication ======================= When you say that solving the "misrepresentation" issue will "clearly not eliminate SPAM", I am not sure I follow you. Perhaps again we don't agree on what constitutes "SPAM". Personally, I don't know that I would include "voice phishing" (THANK YOU for not giving in to the media and calling it "vishing"!) in a definition of SPIT/voice spam. As you indicate, it is often brought about by email scams that entice someone to call a phone number where the listener then hears realistic prompts. I agree this is a problem and I agree that with SIP there are undoubtedly things we could do to help with this. I just don't know that it's something we should incorporate into the first round of "RUCUS". It also goes back to my scoping question above - Reducing Unwanted Communications to *whom*? Per your other note I assume that "underprivileged" was left in by mistake and will disappear from a future draft. 3. Data Mining =========== I understand your rationale for including this, i.e. that an attacker could, for instance, query an ENUM server in preparation for a SPIT attack. Again I wonder if this is something we can address. It does, though, probably fit in the framework of things to consider. 4. B-Side Attacks ============= I don't personally like the name, as it doesn't seem to line up with anything else I've really heard in the security space. Basically what you are defining would be better called "Voice Phishing". As I stated above, it's not clear to me that this is a fit for the BOF or is getting too far out of scope. 5. Lack of Policy ============= I understand what you are getting at here but I'm not sure naming the category "Lack of Policy" works. I don't have a better suggestion right now... perhaps "Policy-related Attacks". I don't know. It's all about "policy", certainly. I also agree that policy is subjective and needs to ultimately be under the recipient's control. There may be days when I don't want to take any phone calls from unknown callers... and their may be other days when I'm in a chatty mood and willing to talk to absolutely anyone who calls. 6. Misrepresentation ================ Again, I'm not entirely comfortable lumping all of RFC 5039 under the heading of "Misrepresentation". I also think that if this is to be a "problem statement" for the BOF it should have some text in here about the attacks rather than simply referring to RFC5039. Just a brief paragraph, perhaps, summarizing the category. 7. Regulatory =========== Agreed this is something that does need to be thought of in the larger picture. I need to think about this document a bit more and also think about what is missing. It seems to me there are some other categories of unwanted communication that aren't there, but right now they aren't jumping out at me. Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-102--412922759 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Okay, so here are some comments about David's "problem statement" as = shown here:

=A0=A0http://www.ietf.org/internet-drafts/draft-schwartz-rucus-= problem-statement-01.txt

First, I do think = documents like this are useful to help us refine what it is we want to = talk about at our meeting in Philadelphia, so thanks, David, for taking = the time to write this.

Stepping through the = document:

1. = Introduction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A = couple of comments:
First, I don't know that I would = characterize the attacks mentioned in RFC5039 only as = "misrepresentation". =A0I view it as broader than that, but then I guess = I have some issues with how you have characterized it (but more on that = in a moment).

Second, you indicate that = this document and by extension this WG/BOF is focusing on "all types of = 'unwanted' commmunications". =A0Perhaps here is where we need to discuss = drawing lines a bit further. =A0=A0When we think of "SPIT" (or whatever = you want to call it), who is the communication attacking? The human = using the device? =A0Or the system? =A0Or both?

When *I* think of "SPIT", = I am thinking of unwanted calls that I (or the voicemail system or other = apps receiving calls on my behalf) receive. I am not necessarily = thinking of system probes (such as perhaps what you define as Data = Mining).

Third, I've already = commented on my view of "What should have been done = earlier".

2. = Unwanted Communication
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
When you say that solving the = "misrepresentation" issue will "clearly not eliminate SPAM", I am not = sure I follow you. Perhaps again we don't agree on what constitutes = "SPAM". =A0

Personally, I don't know = that I would include "voice phishing" (THANK YOU for not giving in to = the media and calling it "vishing"!) in a definition of SPIT/voice spam. = =A0As you indicate, it is often brought about by email scams that entice = someone to call a phone number where the listener then hears realistic = prompts. =A0I agree this is a problem and I agree that with SIP there = are undoubtedly things we could do to help with this. =A0I just don't = know that it's something we should incorporate into the first round of = "RUCUS".

It = also goes back to my scoping question above - Reducing Unwanted = Communications to *whom*?

Per your other note I = assume that "underprivileged" was left in by mistake and will disappear = from a future draft.

3. Data = Mining
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I = understand your rationale for including this, i.e. that an attacker = could, for instance, query an ENUM server in preparation for a SPIT = attack. Again I wonder if this is something we can address. =A0It does, = though, probably fit in the framework of things to = consider.

4. = B-Side Attacks
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I don't personally like the name, as it doesn't seem to line up with = anything else I've really heard in the security space. =A0Basically what = you are defining would be better called "Voice Phishing". =A0As I stated = above, it's not clear to me that this is a fit for the BOF or is getting = too far out of scope.

5. Lack of = Policy
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I = understand what you are getting at here but I'm not sure naming the = category "Lack of Policy" works. =A0I don't have a better suggestion = right now... perhaps "Policy-related Attacks". =A0I don't know. =A0It's = all about "policy", certainly.

I also agree that policy = is subjective and needs to ultimately be under the recipient's control. = =A0There may be days when I don't want to take any phone calls from = unknown callers... and their may be other days when I'm in a chatty mood = and willing to talk to absolutely anyone who calls.

6. = Misrepresentation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Again, I'm not entirely comfortable lumping all of RFC 5039 = under the heading of "Misrepresentation". I also think that if this is = to be a "problem statement" for the BOF it should have some text in here = about the attacks rather than simply referring to RFC5039. =A0Just a = brief paragraph, perhaps, summarizing the category.

7. = Regulatory
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Agreed = this is something that does need to be thought of in the larger = picture.


I need to think about this = document a bit more and also think about what is missing. It seems to me = there are some other categories of unwanted communication that aren't = there, but right now they aren't jumping out at me.

Regards,
Dan
=
--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-102--412922759-- --===============0292441953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============0292441953==-- From rucus-bounces@ietf.org Mon Feb 18 21:52:46 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD133A6781; Mon, 18 Feb 2008 21:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62rDQ5+nwXDX; Mon, 18 Feb 2008 21:52:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D1F3A6962; Mon, 18 Feb 2008 21:52:46 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEC03A6962 for ; Mon, 18 Feb 2008 21:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE6UTGRJgtDT for ; Mon, 18 Feb 2008 21:52:44 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 3615C3A6781 for ; Mon, 18 Feb 2008 21:52:44 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 77D944C3AA; Tue, 19 Feb 2008 06:52:40 +0100 (CET) Date: Tue, 19 Feb 2008 06:52:40 +0100 From: Otmar Lendl To: David Schwartz Message-ID: <20080219055240.GY13520@bofh.priv.at> References: <47B9A5C0.5080704@gmx.net> <20080218211117.GW13520@bofh.priv.at> <95F89869-D234-4D26-AEE8-DBDE6D4ABEF0@xconnect.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <95F89869-D234-4D26-AEE8-DBDE6D4ABEF0@xconnect.net> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: rucus@ietf.org Subject: Re: [Rucus] [Fwd: I-D Action:draft-schwartz-rucus-problem-statement-01.txt] X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/18 22:02, David Schwartz wrote: > On Feb 18, 2008, at 11:11 PM, Otmar Lendl wrote: > > >I'm missing DoS (intentional and by software error) as category for > >"unwanted communication". > > DS: I didn't want to turn this into a general "VoIP Threat document" > so I tried to focus on end-to-end communication threats (including > number harvesting which leads to a call). (The "underprivileged" > remained in by accident as this too is more of a system threat than an > "unwanted communication" one.) David, the scoping makes sense as you propose it. It might be helpful for your draft to explicitely list a few things that you intentionally left out of scope in order to make it clear that they were not forgotten. /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 18 23:24:53 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887B228C3E6; Mon, 18 Feb 2008 23:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ir21qtcLrDYz; Mon, 18 Feb 2008 23:24:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8734228C419; Mon, 18 Feb 2008 23:24:52 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8726628C419 for ; Mon, 18 Feb 2008 23:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQjksRy4yQEl for ; Mon, 18 Feb 2008 23:24:50 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2239C28C3E3 for ; Mon, 18 Feb 2008 23:24:49 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2008 07:24:46 -0000 Received: from proxy2-nsn.nsn-inter.net (EHLO [217.115.75.230]) [217.115.75.230] by mail.gmx.net (mp054) with SMTP; 19 Feb 2008 08:24:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19HlZhKtS9H6QuSslHIchkXL0Lj+DDuGiajnZoJSA 1zIWyihRGOPVit Message-ID: <47BA843D.6050708@gmx.net> Date: Tue, 19 Feb 2008 09:24:45 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dan York References: <20080218201501.60A6A28C54D@core3.amsl.com> <865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com> In-Reply-To: <865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com> X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] SIP scenarios similar to SPIT - Fwd: I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Dan, I believe this is an interesting document since it challenges the capabilities of statistical learning algorithms some people have been excited about. Ciao Hannes Dan York wrote: > RUCUS members, > > FYI, based on the feedback of a number of folks, I did submit a new > version of this document today. It is still tagged -00 because this > time I added the workgroup name to the file name (which I missed doing > when I originally posted it as > draft-york-spit-similarity-scenarios-00.txt): > > > http://www.ietf.org/internet-drafts/draft-york-sipping-spit-similarity-scenarios-00.txt > > > It has, however, changed slightly from the first draft as I > incorporated a few more scenarios suggested by people and also broke > out the inbound scenarios a bit more. > > Feedback is of course definitely welcome. As we talk about potential > architectures to address SPIT, my intent really is to highlight the > fact that there are scenarios where legitimate SIP traffic might > easily be mistaken for one form of SPIT. > > Regards, > Dan > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: February 18, 2008 3:15:01 PM EST >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : SIP Usage Scenarios Similar to SPIT >> Author(s) : D. York >> Filename : >> draft-york-sipping-spit-similarity-scenarios-00.txt >> Pages : 11 >> Date : 2008-02-18 >> >> This document outlines scenarios in which legitimate SIP traffic may >> appear similar to traffic associated with voice spam, also known as >> "SPIT" or "Spam for Internet Telephony. This document is created to >> provide input into the current discussions about how best to address >> the issue of SPIT. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-york-sipping-spit-similarity-scenarios-00.txt >> >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-york-sipping-spit-similarity-scenarios-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE >> /internet-drafts/draft-york-sipping-spit-similarity-scenarios-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2008-02-18120051.I-D\@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> http://www.ietf.org/mailman/listinfo/i-d-announce > > ------------------------------------------------------------------------ > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 00:16:43 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D7C28C42E; Tue, 19 Feb 2008 00:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AkpLQLBrhn5; Tue, 19 Feb 2008 00:16:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9547F28C178; Tue, 19 Feb 2008 00:16:42 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B43628C178 for ; Tue, 19 Feb 2008 00:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p3U+2FZD32D for ; Tue, 19 Feb 2008 00:16:39 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 10A3F3A696D for ; Tue, 19 Feb 2008 00:16:38 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1J8GYl9003633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 09:16:34 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1J8GXXF010099; Tue, 19 Feb 2008 09:16:34 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Feb 2008 09:16:33 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 19 Feb 2008 09:16:28 +0100 Message-ID: In-Reply-To: <20080219055240.GY13520@bofh.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] [Fwd: I-DAction:draft-schwartz-rucus-problem-statement-01.txt] Thread-Index: AchyvJx1IaTidXC+QtSc7nWwVwCYOQADyuzw References: <47B9A5C0.5080704@gmx.net> <20080218211117.GW13520@bofh.priv.at><95F89869-D234-4D26-AEE8-DBDE6D4ABEF0@xconnect.net> <20080219055240.GY13520@bofh.priv.at> From: "Charzinski, Joachim (NSN - DE/Muenich)" To: "ext Otmar Lendl" , "David Schwartz" X-OriginalArrivalTime: 19 Feb 2008 08:16:33.0464 (UTC) FILETIME=[BCFE5380:01C872CF] Cc: rucus@ietf.org Subject: Re: [Rucus] [Fwd: I-DAction:draft-schwartz-rucus-problem-statement-01.txt] X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > > >I'm missing DoS (intentional and by software error) as category for > > >"unwanted communication". > > = > > DS: I didn't want to turn this into a general "VoIP Threat = > document" = > > so I tried to focus on end-to-end communication threats (including = > > number harvesting which leads to a call). (The "underprivileged" = > > remained in by accident as this too is more of a system = > threat than an = > > "unwanted communication" one.) > = > David, > = > the scoping makes sense as you propose it. = > = > It might be helpful for your draft to explicitely list a few things > that you intentionally left out of scope in order to make it clear > that they were not forgotten. Does that mean you want to deal with unwanted communication only = up to the degree that it is still nuisance and not yet DoS? = In my opinion, there is a continuum of cases between simple nuisance and real DoS, which is hard to distinguish technically. = Just consider these two DoS-by-SPIT examples: 1. private subscribers receive so many annoying calls that they do = not pick up the phone anymore 2. enterprise line (fixed or mobile) receives a large number of calls = (e.g. >20) during the night that are recorded on the voice box. The next morning, the targeted employee will waste a lot of time = listening to the calls. If the calls targeted a larger number of = employees, it might even lead to instability of the voice box = system. Is there any good reason for excluding these scenarios? Their intent = might be different, but the technical methods and thus the appearance = in the network will be similar to "ordinary" SPIT. = Joachim. ---------------------------------------------------------- Nokia Siemens Networks Joachim Charzinski Principal Innovator Visitor address: Machtlfinger Str. 1 / D-81379 Muenchen / Germany Postal address: D-80240 Muenchen / Germany Tel: +49 89 722 46803 / Joachim.Charzinski@nsn.com / http://www.nokiasiemen= snetworks.com/global/ = Think before you print Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft: M=FCnchen / R= egistered office: Munich - Registergericht: M=FCnchen / Commercial registry= : Munich, HRA 88537 - WEEE-Reg.-Nr.: DE 52984304 - Pers=F6nlich haftende Ge= sellschafterin / General Partner: Nokia Siemens Networks Management GmbH - = Gesch=E4ftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer - S= itz der Gesellschaft: M=FCnchen / Registered office: Munich - Registergeric= ht: M=FCnchen / Commercial registry: Munich, HRB 163416 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 01:35:45 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD56528C4CA; Tue, 19 Feb 2008 01:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os1WOASs9NCj; Tue, 19 Feb 2008 01:35:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E8328C454; Tue, 19 Feb 2008 01:35:45 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AB6328C454 for ; Tue, 19 Feb 2008 01:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-XInHU7+sYN for ; Tue, 19 Feb 2008 01:35:43 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 47FB128C431 for ; Tue, 19 Feb 2008 01:35:42 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 23AE04C3AA; Tue, 19 Feb 2008 10:35:39 +0100 (CET) Date: Tue, 19 Feb 2008 10:35:39 +0100 From: Otmar Lendl To: rucus@ietf.org Message-ID: <20080219093539.GA27334@bofh.priv.at> References: <20080218201501.60A6A28C54D@core3.amsl.com> <865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com> <47BA843D.6050708@gmx.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <47BA843D.6050708@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [Rucus] SIP scenarios similar to SPIT - Fwd: I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/19 08:02, Hannes Tschofenig wrote: > Hi Dan, > > I believe this is an interesting document since it challenges the > capabilities of statistical learning algorithms some people have been > excited about. I agree, this is a good contribution and a valuable reality-check. Another thing which might throw a wrench into a lot of anti-spit ideas (including mine) is the proliferation of bot-nets. In the email world, these account for the majority of spam already and I wonder what they could do to SIP. /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 01:50:40 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2153228C110; Tue, 19 Feb 2008 01:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=-1.347, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a-4bGK5rrl8; Tue, 19 Feb 2008 01:50:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B08928C19E; Tue, 19 Feb 2008 01:50:39 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E7628C19E for ; Tue, 19 Feb 2008 01:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gwbob7AeeyOX for ; Tue, 19 Feb 2008 01:50:37 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BD01628C110 for ; Tue, 19 Feb 2008 01:50:37 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2008 01:50:35 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1J9oZJH020401; Tue, 19 Feb 2008 01:50:35 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1J9oYJg014937; Tue, 19 Feb 2008 09:50:34 GMT From: "Dan Wing" To: "'Otmar Lendl'" , References: <20080218201501.60A6A28C54D@core3.amsl.com><865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com><47BA843D.6050708@gmx.net> <20080219093539.GA27334@bofh.priv.at> Date: Tue, 19 Feb 2008 01:50:34 -0800 Message-ID: <059e01c872dc$dfaf5340$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080219093539.GA27334@bofh.priv.at> Thread-Index: Achy2tTgxujlH2qgSYCAK1b3NcXf7gAATOrg Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Rucus] SIP scenarios similar to SPIT - Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > > I believe this is an interesting document since it challenges the > > capabilities of statistical learning algorithms some people > > have been excited about. > > I agree, this is a good contribution and a valuable reality-check. > > Another thing which might throw a wrench into a lot of anti-spit ideas > (including mine) is the proliferation of bot-nets. In the email world, > these account for the majority of spam already and I wonder what they > could do to SIP. The computing power available to a botnet means that computational puzzles (Section 3.9 of RFC5039) are ineffective -- the botnet itself would be tasked with solving the computational puzzle. If the computer itself is compromised (versus just having an unauthorized application running on it), then the user's identity can be stolen. A stolen identity would render some of the other RFC5039 techniques (reputation systems and white lists) less effective or ineffective. -d _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 02:55:30 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7A028C50D; Tue, 19 Feb 2008 02:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.074 X-Spam-Level: X-Spam-Status: No, score=0.074 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZUaEGd2qIKZ; Tue, 19 Feb 2008 02:55:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4FC28C48D; Tue, 19 Feb 2008 02:55:29 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5159328C4D8 for ; Tue, 19 Feb 2008 02:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rySILWIKScLM for ; Tue, 19 Feb 2008 02:55:27 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 96A073A6DFA for ; Tue, 19 Feb 2008 02:55:26 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28059133; Tue, 19 Feb 2008 10:55:22 +0000 In-Reply-To: <20080219093539.GA27334@bofh.priv.at> References: <20080218201501.60A6A28C54D@core3.amsl.com> <865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com> <47BA843D.6050708@gmx.net> <20080219093539.GA27334@bofh.priv.at> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <0B761124-2C2F-4B92-8A9A-5301C736BE32@voxeo.com> From: Dan York Date: Tue, 19 Feb 2008 05:55:20 -0500 To: Otmar Lendl X-Mailer: Apple Mail (2.753) Cc: rucus@ietf.org Subject: Re: [Rucus] SIP scenarios similar to SPIT - Fwd: I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1923164192==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1923164192== Content-Type: multipart/alternative; boundary=Apple-Mail-103--374462287 --Apple-Mail-103--374462287 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 19, 2008, at 4:35 AM, Otmar Lendl wrote: > On 2008/02/19 08:02, Hannes Tschofenig > wrote: >> Hi Dan, >> >> I believe this is an interesting document since it challenges the >> capabilities of statistical learning algorithms some people have been >> excited about. > > I agree, this is a good contribution and a valuable reality-check. Thank you both for your kind words. > Another thing which might throw a wrench into a lot of anti-spit ideas > (including mine) is the proliferation of bot-nets. In the email world, > these account for the majority of spam already and I wonder what they > could do to SIP. Yes, botnets certainly could add challenges. Proof-of-concept bots that focus entirely on SIP are also out there in the wild. I wrote about one (with a focus on the DDoS potential) back in May 2007 here: http://voipsa.org/blog/2007/05/07/ready-or-not-here-come-the-irc- controlled-sipvoip-attack-bots/ Since that time I haven't personally seen any more work being exposed around SIP-related bots. (but then again, *would* I if the botherders are seriously about it? :-) I don't know that the financial circumstances are there yet for a bot herder to move into the SIP space (i.e. there probably aren't enough SIP endpoints and trunks out there *yet* to merit moving into the space. More money can still be made in email spam or DDoS.) I don't know that we need to be hugely concerned about botnets in your near-term thinking about combatting SPIT, but I do agree that any larger architecture we look at should consider the fact that massively distributed "attacks" of voice spam by botnets could at some point become a reality. (and could indeed look like some of the scenarios I outlined in my document) Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-103--374462287 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Feb 19, 2008, at 4:35 AM, Otmar Lendl wrote:

On 2008/02/19 08:02, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>= ; wrote:
Hi = Dan,

I believe this is an interesting document since it = challenges the=A0
capabilities of statistical learning algorithms some = people have been=A0
excited about.

I agree, = this is a good contribution and a valuable = reality-check.

Thank you both for your kind = words.

Another thing which might = throw a wrench into a lot of anti-spit ideas
(including mine) is the proliferation of bot-nets. = In the email world,
these account for the = majority of spam already and I wonder what they
could do to SIP.

Yes, botnets certainly could = add challenges. Proof-of-concept bots that focus entirely on SIP are = also out there in the wild. I wrote about one (with a focus on the DDoS = potential) back in May 2007 here:


Since that time I haven't = personally seen any more work being exposed around SIP-related bots. = (but then again, *would* I if the botherders are seriously about it? :-) = =A0I don't know that the financial circumstances are there yet for a bot = herder to move into the SIP space (i.e. there probably aren't enough SIP = endpoints and trunks out there *yet* to merit moving into the space. = More money can still be made in email spam or = DDoS.)

I don't know that we need to be hugely = concerned about botnets in your near-term thinking about combatting = SPIT, but I do agree that any larger architecture we look at should = consider the fact that massively distributed "attacks" of voice spam by = botnets could at some point become a reality. =A0(and could indeed look = like some of the scenarios I outlined in my document)

Regards,
Dan
=

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-103--374462287-- --===============1923164192== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1923164192==-- From rucus-bounces@ietf.org Tue Feb 19 03:28:04 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BBC428C4B1; Tue, 19 Feb 2008 03:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bGiFC9tHoDc; Tue, 19 Feb 2008 03:28:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E8D3A6A1A; Tue, 19 Feb 2008 03:28:02 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D405428C3BC for ; Tue, 19 Feb 2008 03:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoMbalcfPFIG for ; Tue, 19 Feb 2008 03:28:00 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2C1433A697C for ; Tue, 19 Feb 2008 03:28:00 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 62B7B2C009E90 for ; Tue, 19 Feb 2008 12:27:57 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7RRoFx-TsMh for ; Tue, 19 Feb 2008 12:27:57 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 5136F2C002B4A for ; Tue, 19 Feb 2008 12:27:52 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 12:27:51 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D108F@mx1.office> In-Reply-To: <20080218205531.GU13520@bofh.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] [spitstop] Context for rucus Thread-Index: AchycJ3nIfqN0EmpTuihibafdYO0sgAeTfaA References: <20080215214731.GE13520@bofh.priv.at> <5F6519BF2DE0404D99B7C75607FF76FF4D0F01@mx1.office> <20080218205531.GU13520@bofh.priv.at> From: "Saverio Niccolini" To: "rucus BoF" Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > What I really care about is a common understanding on the > basic communication ecosystem for which we try to develop a solution. > > (IMHO that's missing in speermint, which might be the most > important reason that speermint hasn't produced any > worthwhile output so far.) The objective of SPEERMINT was supposed to be on a different plane than RUCUS. I agree that this is a problem in SPEERMINT but this does not mean that we should solve this problem to be able to work on RUCUS. There is already a kind of "problem statement" for SIP spam (even already an RFC, RFC 5039), we should rely on this and buld an architecture and requirements on top of that. That is straightforward for me... Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 03:30:58 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719BF28C3EB; Tue, 19 Feb 2008 03:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.471 X-Spam-Level: X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRbvWErz7P3Q; Tue, 19 Feb 2008 03:30:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF55D3A6A2D; Tue, 19 Feb 2008 03:30:57 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FD228C3BC for ; Tue, 19 Feb 2008 03:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP63f+djB-Jo for ; Tue, 19 Feb 2008 03:30:56 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 370083A6990 for ; Tue, 19 Feb 2008 03:30:56 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6DCC42C002B4A for ; Tue, 19 Feb 2008 12:30:53 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQncVHDzVpje for ; Tue, 19 Feb 2008 12:30:53 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 328872C000355 for ; Tue, 19 Feb 2008 12:30:48 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 12:30:47 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D1090@mx1.office> In-Reply-To: <20080218213802.GX13520@bofh.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] [spitstop] Context for rucus Thread-Index: AchydpqdLXJE3RlcSrKnwAGF7GQn1gAc/dgw References: <20080215161045.GC13520@bofh.priv.at><124401c87003$ea9930e0$c4f0200a@cisco.com><20080215194050.GD13520@bofh.priv.at><139b01c8700e$876e1250$c4f0200a@cisco.com><20080215214731.GE13520@bofh.priv.at><01a101c8701e$5f2c07b0$c4f0200a@cisco.com><20080218205105.GT13520@bofh.priv.at><02f901c87271$0dad47f0$c4f0200a@cisco.com> <20080218213802.GX13520@bofh.priv.at> From: "Saverio Niccolini" To: "rucus BoF" Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > ... which brings us to a crucial question: > > Can the "white list" approach work in a a PSTN-replacement service? I do not think the "white list" approach on its own is enough. There are too many problems with it: -- identity spoofing -- providers giving away identities for free (or for good money) to telemarketers -- virus and trojans in devices White list and identities are not enough. Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 03:32:22 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8CBE28C525; Tue, 19 Feb 2008 03:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXO4oUogPOKO; Tue, 19 Feb 2008 03:32:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD7828C48D; Tue, 19 Feb 2008 03:32:20 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA093A6895 for ; Tue, 19 Feb 2008 03:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQyOcihkd-C2 for ; Tue, 19 Feb 2008 03:32:18 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id AE22928C3EB for ; Tue, 19 Feb 2008 03:31:53 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id E90F92C002B4A for ; Tue, 19 Feb 2008 12:31:50 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeTtFF5A4ure for ; Tue, 19 Feb 2008 12:31:50 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id D88DD2C000355 for ; Tue, 19 Feb 2008 12:31:45 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 12:31:45 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D1091@mx1.office> In-Reply-To: <038c01c87278$a54b32f0$c4f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] [spitstop] Context for rucus Thread-Index: AchydthCERDAhNwBRxS/ogTxgjjGowAAMyxwABzQ7kA= References: <20080215161045.GC13520@bofh.priv.at><124401c87003$ea9930e0$c4f0200a@cisco.com><20080215194050.GD13520@bofh.priv.at><139b01c8700e$876e1250$c4f0200a@cisco.com><20080215214731.GE13520@bofh.priv.at><01a101c8701e$5f2c07b0$c4f0200a@cisco.com><20080218205105.GT13520@bofh.priv.at><02f901c87271$0dad47f0$c4f0200a@cisco.com><20080218213802.GX13520@bofh.priv.at> <038c01c87278$a54b32f0$c4f0200a@cisco.com> From: "Saverio Niccolini" To: "rucus BoF" Subject: Re: [Rucus] [spitstop] Context for rucus X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Dan Wing > Sent: Monday, February 18, 2008 10:53 PM > To: 'Otmar Lendl' > Cc: rucus@ietf.org; 'Signaling TO Prevent SPIT' > Subject: Re: [Rucus] [spitstop] Context for rucus > > > > > If I create an identity on, say, gmail.com, and it is my > identity on > > > publicly-facing documents, presentations I give, columns I write, > > > email that I post to mailing lists, hand out dozens of business > > > cards with my email address, etc., I can't just "pack up my bags" > > > (so to speak) and jump to a different email provider. > > > > Well, the "official solutions" to that problem in email and > telephony > > are "get your own domain" and "number portability". > > > > Once you de-couple your address from your provider, packing > the bags > > and moving is no issue. > > Ok. > > > > I expect the same would be true of my identity on Skype, > IM networks > > > (Yahoo, Hotmail, MSN, etc.). It's true I could pack up and leave > > > those, but packing up and leaving those networks is not > trivial or > > > easy. I would need to get re-added on all of my friend's white > > > lists (which is the only viable mechanism on those > networks for me > > > and for my friends to avoid getting spammed by > advertising when on > > > those networks). > > > > ... which brings us to a crucial question: > > > > Can the "white list" approach work in a a PSTN-replacement service? > > > > ("work" in that context needs to be technical, from a UI > perspective, > > and from a service expectation point of view.) > > White lists only work if there is a separate, out-of-band > mechanism to communicate to someone before you are on their > white list. Even then they fail in many scenarios (see my previous email) Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 04:41:10 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2488928C543; Tue, 19 Feb 2008 04:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNHa29l+Q7uj; Tue, 19 Feb 2008 04:41:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616293A69D0; Tue, 19 Feb 2008 04:41:09 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00DE13A69D0 for ; Tue, 19 Feb 2008 04:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fs-7jozXX1d for ; Tue, 19 Feb 2008 04:41:08 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id DBF603A68A6 for ; Tue, 19 Feb 2008 04:41:07 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1637C2C009E90; Tue, 19 Feb 2008 13:41:05 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8e3s7ts9P9H; Tue, 19 Feb 2008 13:41:05 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 002B02C000355; Tue, 19 Feb 2008 13:40:49 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 13:40:49 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D10A0@mx1.office> In-Reply-To: <059e01c872dc$dfaf5340$c4f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] SIP scenarios similar to SPIT -Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt Thread-Index: Achy2tTgxujlH2qgSYCAK1b3NcXf7gAATOrgAAXtLBA= References: <20080218201501.60A6A28C54D@core3.amsl.com><865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com><47BA843D.6050708@gmx.net><20080219093539.GA27334@bofh.priv.at> <059e01c872dc$dfaf5340$c4f0200a@cisco.com> From: "Martin Stiemerling" To: "Dan Wing" , "Otmar Lendl" , Subject: Re: [Rucus] SIP scenarios similar to SPIT -Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi, [...] > > The computing power available to a botnet means that > computational puzzles (Section 3.9 of RFC5039) are > ineffective -- the botnet itself would be tasked with solving > the computational puzzle. > > If the computer itself is compromised (versus just having an > unauthorized application running on it), then the user's > identity can be stolen. A stolen identity would render some > of the other > RFC5039 techniques (reputation systems and white lists) less > effective or ineffective. ...which has been just reported today in German networking/computer news. I have only the news report in German as I didn't find any English version yet (http://www.heise.de/newsticker/meldung/103711) The report basically points out that email spammers have just climbed the brarrier of white lists and reputation systems. They are hacking in email accounts of regular users and use their accounts to send spam to others. Just my 2 cents, Martin stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 05:52:35 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC59628C5AA; Tue, 19 Feb 2008 05:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoaOXPTPkm-X; Tue, 19 Feb 2008 05:52:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEB528C592; Tue, 19 Feb 2008 05:52:35 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5471328C592 for ; Tue, 19 Feb 2008 05:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHKB9X+vcjin for ; Tue, 19 Feb 2008 05:52:33 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4E84828C55B for ; Tue, 19 Feb 2008 05:52:33 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 7B93A2C00C336 for ; Tue, 19 Feb 2008 14:52:30 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHKQzW+r+rqK for ; Tue, 19 Feb 2008 14:52:30 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 6AEB62C000357 for ; Tue, 19 Feb 2008 14:52:25 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 14:52:24 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D10CF@mx1.office> In-Reply-To: <0B761124-2C2F-4B92-8A9A-5301C736BE32@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] SIP scenarios similar to SPIT - Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt Thread-Index: Achy5f7rA1N0VLveSWugILKzKZRlhAAGEBCA References: <20080218201501.60A6A28C54D@core3.amsl.com><865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com><47BA843D.6050708@gmx.net> <20080219093539.GA27334@bofh.priv.at> <0B761124-2C2F-4B92-8A9A-5301C736BE32@voxeo.com> From: "Saverio Niccolini" To: "rucus BoF" Subject: Re: [Rucus] SIP scenarios similar to SPIT - Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > I don't know that we need to be hugely concerned about > botnets in your near-term thinking about combatting SPIT, but > I do agree that any larger architecture we look at should > consider the fact that massively distributed "attacks" of > voice spam by botnets could at some point become a reality. > (and could indeed look like some of the scenarios I outlined > in my document) I think we do need to be concerned about bot-nets. They are the main source of email spam and they are the reason why many of us agree that white list and reputation system are not enough for fighting SPIT. Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 06:01:03 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6D228C5A3; Tue, 19 Feb 2008 06:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6c2AU8gqeGf9; Tue, 19 Feb 2008 06:01:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF3528C580; Tue, 19 Feb 2008 06:01:02 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A116928C580 for ; Tue, 19 Feb 2008 06:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g264ykkNYffa for ; Tue, 19 Feb 2008 06:01:00 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 62C5128C4F7 for ; Tue, 19 Feb 2008 06:00:59 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2008 14:00:56 -0000 Received: from proxy4-nsn.nsn-inter.net (EHLO [217.115.75.232]) [217.115.75.232] by mail.gmx.net (mp008) with SMTP; 19 Feb 2008 15:00:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18qaHA71+0qhDI1mVCBCaUEM5LafCRsONvXJzQ3sN nyWF/0cY2tJv9p Message-ID: <47BAE11F.4030303@gmx.net> Date: Tue, 19 Feb 2008 16:01:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Saverio Niccolini References: <20080218201501.60A6A28C54D@core3.amsl.com><865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com><47BA843D.6050708@gmx.net> <20080219093539.GA27334@bofh.priv.at> <0B761124-2C2F-4B92-8A9A-5301C736BE32@voxeo.com> <5F6519BF2DE0404D99B7C75607FF76FF4D10CF@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D10CF@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] SIP scenarios similar to SPIT - Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Botnets is the killer argument for almost all solutions. I wouldn't therefore conclude that whitelists are useless. What solution does help against botnets? Saverio Niccolini wrote: >> I don't know that we need to be hugely concerned about >> botnets in your near-term thinking about combatting SPIT, but >> I do agree that any larger architecture we look at should >> consider the fact that massively distributed "attacks" of >> voice spam by botnets could at some point become a reality. >> (and could indeed look like some of the scenarios I outlined >> in my document) >> > > I think we do need to be concerned about bot-nets. They are the main > source of email spam and they are the reason why many of us agree that > white list and reputation system are not enough for fighting SPIT. > > Saverio > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 06:04:00 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77DA28C5D2; Tue, 19 Feb 2008 06:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIgwemilsJIC; Tue, 19 Feb 2008 06:03:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18C328C5A5; Tue, 19 Feb 2008 06:03:59 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C1928C5BB for ; Tue, 19 Feb 2008 06:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKEXP-P6YwN2 for ; Tue, 19 Feb 2008 06:03:57 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3205628C5A5 for ; Tue, 19 Feb 2008 06:03:57 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 60B3B2C01D460 for ; Tue, 19 Feb 2008 15:03:54 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc2xC69ETqML for ; Tue, 19 Feb 2008 15:03:54 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 503FC2C000357 for ; Tue, 19 Feb 2008 15:03:49 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 15:03:48 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D10D7@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D10CF@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] SIP scenarios similar to SPIT -Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt Thread-Index: Achy5f7rA1N0VLveSWugILKzKZRlhAAGEBCAAAB+bjA= References: <20080218201501.60A6A28C54D@core3.amsl.com><865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com><47BA843D.6050708@gmx.net><20080219093539.GA27334@bofh.priv.at><0B761124-2C2F-4B92-8A9A-5301C736BE32@voxeo.com> <5F6519BF2DE0404D99B7C75607FF76FF4D10CF@mx1.office> From: "Martin Stiemerling" To: "Saverio Niccolini" , "rucus BoF" Subject: Re: [Rucus] SIP scenarios similar to SPIT -Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org +1. > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Saverio Niccolini > Sent: Tuesday, February 19, 2008 2:52 PM > To: rucus BoF > Subject: Re: [Rucus] SIP scenarios similar to SPIT -Fwd:I-D > Action:draft-york-sipping-spit-similarity-scenarios-00.txt > > > I don't know that we need to be hugely concerned about > botnets in your > > near-term thinking about combatting SPIT, but I do agree that any > > larger architecture we look at should consider the fact > that massively > > distributed "attacks" of voice spam by botnets could at some point > > become a reality. > > (and could indeed look like some of the scenarios I outlined in my > > document) > > I think we do need to be concerned about bot-nets. They are > the main source of email spam and they are the reason why > many of us agree that white list and reputation system are > not enough for fighting SPIT. > > Saverio > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 06:04:15 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A359A28C5D4; Tue, 19 Feb 2008 06:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeAan-mNehHg; Tue, 19 Feb 2008 06:04:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F6428C5BB; Tue, 19 Feb 2008 06:04:14 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A9F28C5BB for ; Tue, 19 Feb 2008 06:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Omq078VgrqU for ; Tue, 19 Feb 2008 06:04:12 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4591B28C512 for ; Tue, 19 Feb 2008 06:04:12 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6D4582C01D51A; Tue, 19 Feb 2008 15:04:09 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tSURUX9Ri+z; Tue, 19 Feb 2008 15:04:09 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 5765D2C000357; Tue, 19 Feb 2008 15:03:54 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 15:03:49 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D10D8@mx1.office> In-Reply-To: <47BA843D.6050708@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] SIP scenarios similar to SPIT - Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt Thread-Index: AchyyKBHlEqyjqrxQf+1ixuhXoUHUgANwuQw References: <20080218201501.60A6A28C54D@core3.amsl.com><865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com> <47BA843D.6050708@gmx.net> From: "Saverio Niccolini" To: , "Dan York" Cc: rucus BoF Subject: Re: [Rucus] SIP scenarios similar to SPIT - Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes and others, > I believe this is an interesting document since it challenges > the capabilities of statistical learning algorithms some > people have been excited about. I think there is a misunderstanding here, please read: http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam-score-semantics-00.txt it is not about statistical methods, the main reasons are others, see section "2.1. Proposal motivation". Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 06:05:27 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC6B28C5C3; Tue, 19 Feb 2008 06:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.632 X-Spam-Level: X-Spam-Status: No, score=-0.632 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k72G7948Gc8w; Tue, 19 Feb 2008 06:05:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A690828C5B9; Tue, 19 Feb 2008 06:05:26 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581D028C591 for ; Tue, 19 Feb 2008 06:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtmqinI7bLsA for ; Tue, 19 Feb 2008 06:05:24 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3A7E128C512 for ; Tue, 19 Feb 2008 06:05:24 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 687E12C000357; Tue, 19 Feb 2008 15:05:21 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IECuEI56R72I; Tue, 19 Feb 2008 15:05:21 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 54F0C2C000355; Tue, 19 Feb 2008 15:05:11 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 15:05:10 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D10D9@mx1.office> In-Reply-To: <47BAE11F.4030303@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] SIP scenarios similar to SPIT- Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt Thread-Index: Achy/+rszi2zKJTMRz6XjqDkEcbU+AAAFX5w References: <20080218201501.60A6A28C54D@core3.amsl.com><865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com><47BA843D.6050708@gmx.net> <20080219093539.GA27334@bofh.priv.at> <0B761124-2C2F-4B92-8A9A-5301C736BE32@voxeo.com><5F6519BF2DE0404D99B7C75607FF76FF4D10CF@mx1.office> <47BAE11F.4030303@gmx.net> From: "Martin Stiemerling" To: , "Saverio Niccolini" Cc: rucus BoF Subject: Re: [Rucus] SIP scenarios similar to SPIT- Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > > Botnets is the killer argument for almost all solutions. It is not a killer argument for all solutions but it is a serious threat that needs to be considered. I also don't see this as Saverion's point. > I wouldn't therefore conclude that whitelists are useless. Nobody did, but they are not enough anymore. > What solution does help against botnets? No idea yet. Martin > > Saverio Niccolini wrote: > >> I don't know that we need to be hugely concerned about botnets in > >> your near-term thinking about combatting SPIT, but I do agree that > >> any larger architecture we look at should consider the fact that > >> massively distributed "attacks" of voice spam by botnets could at > >> some point become a reality. > >> (and could indeed look like some of the scenarios I outlined in my > >> document) > >> > > > > I think we do need to be concerned about bot-nets. They are the main > > source of email spam and they are the reason why many of us > agree that > > white list and reputation system are not enough for fighting SPIT. > > > > Saverio > > > > ============================================================ > > Dr. Saverio Niccolini > > Senior Researcher > > NEC Laboratories Europe, Network Research Division > > Kurfuerstenanlage 36, D-69115 Heidelberg > > Tel. +49 (0)6221 4342-118 > > Fax: +49 (0)6221 4342-155 > > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > > ============================================================ > > NEC Europe Limited Registered Office: NEC House, 1 Victoria > > Road, London W3 6BL Registered in England 2832014 > > _______________________________________________ > > Rucus mailing list > > Rucus@ietf.org > > http://www.ietf.org/mailman/listinfo/rucus > > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 06:56:38 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DFEA28C5A5; Tue, 19 Feb 2008 06:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.62 X-Spam-Level: X-Spam-Status: No, score=-0.62 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0876Id2ytpx; Tue, 19 Feb 2008 06:56:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99A03A6ACC; Tue, 19 Feb 2008 06:56:37 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485F13A6ACC for ; Tue, 19 Feb 2008 06:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT6B8OoTTYOV for ; Tue, 19 Feb 2008 06:56:36 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 475C73A6A9F for ; Tue, 19 Feb 2008 06:56:35 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 322AB4C3F4; Tue, 19 Feb 2008 15:56:32 +0100 (CET) Date: Tue, 19 Feb 2008 15:56:32 +0100 From: Otmar Lendl To: Martin Stiemerling Message-ID: <20080219145632.GZ13520@bofh.priv.at> References: <059e01c872dc$dfaf5340$c4f0200a@cisco.com> <5F6519BF2DE0404D99B7C75607FF76FF4D10A0@mx1.office> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D10A0@mx1.office> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: rucus@ietf.org Subject: Re: [Rucus] SIP scenarios similar to SPIT -Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/19 13:02, Martin Stiemerling wrote: > > ...which has been just reported today in German networking/computer > news. I have only the news report in German as I didn't find any > English version yet (http://www.heise.de/newsticker/meldung/103711) > > The report basically points out that email spammers have just climbed > the brarrier of white lists and reputation systems. They are hacking > in email accounts of regular users and use their accounts to send spam > to others. Putting on my cynic's hat, this is actually a good development: Up to now, a lot of people didn't care about whether their PC was zombified and sending out spam, as it didn't affect their use of the box. If the spammer are now really using the mail account of the user, then the malware might no longer be that invisible to user. /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 07:06:25 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45BDD28C64A; Tue, 19 Feb 2008 07:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XktGBLSvf2Cn; Tue, 19 Feb 2008 07:06:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A7728C63C; Tue, 19 Feb 2008 07:06:24 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FA028C645 for ; Tue, 19 Feb 2008 07:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEompS2C3Uro for ; Tue, 19 Feb 2008 07:06:21 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 4BA1728C63C for ; Tue, 19 Feb 2008 07:06:21 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28061485 for rucus@ietf.org; Tue, 19 Feb 2008 15:06:16 +0000 Mime-Version: 1.0 (Apple Message framework v753) To: rucus BoF Message-Id: From: Dan York Date: Tue, 19 Feb 2008 10:06:14 -0500 X-Mailer: Apple Mail (2.753) Subject: [Rucus] FYI, RUCUS list membership is now at... X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1312458683==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1312458683== Content-Type: multipart/alternative; boundary=Apple-Mail-111--359408552 --Apple-Mail-111--359408552 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed ... 61 members, so we have seen a good number of the SPITSTOP subscribers move over. (And as list admin I can tell you that a large number of the "usual suspects" in RAI working groups are subscribed to RUCUS even though they may mostly be lurking at the moment.) Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-111--359408552 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 ... 61 members, so we have seen a good number of the SPITSTOP = subscribers move over. (And as list admin I can tell you that a large = number of the "usual suspects" in RAI working groups are subscribed to = RUCUS even though they may mostly be lurking at the moment.)

Regards,
Dan
=

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-111--359408552-- --===============1312458683== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1312458683==-- From rucus-bounces@ietf.org Tue Feb 19 07:19:36 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0AE28C53D; Tue, 19 Feb 2008 07:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQMW5BhGW-+o; Tue, 19 Feb 2008 07:19:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557EC3A6A87; Tue, 19 Feb 2008 07:19:35 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB65E28C53D for ; Tue, 19 Feb 2008 07:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH-gKYxnzIFv for ; Tue, 19 Feb 2008 07:19:34 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id BC0413A6A87 for ; Tue, 19 Feb 2008 07:19:33 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28061679 for rucus@ietf.org; Tue, 19 Feb 2008 15:19:30 +0000 Mime-Version: 1.0 (Apple Message framework v753) To: rucus BoF Message-Id: From: Dan York Date: Tue, 19 Feb 2008 10:19:28 -0500 X-Mailer: Apple Mail (2.753) Subject: [Rucus] FYI - RUCUS web archive is not updating... ticket has been filed X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1943400718==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1943400718== Content-Type: multipart/alternative; boundary=Apple-Mail-114--358614765 --Apple-Mail-114--358614765 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed RUCUS members, FYI, while the RUCUS mailing list archive is now *visible* at: http://www.ietf.org/mail-archive/web/rucus/current/maillist.html it is not updating with recent messages. I've raised a ticket with ietf-action to get this resolved. Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-114--358614765 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 RUCUS members,

FYI, = while the RUCUS mailing list archive is now *visible* at:

=

it is not = updating with recent messages. =A0I've raised a ticket with ietf-action = to get this resolved.

Dan

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-114--358614765-- --===============1943400718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1943400718==-- From rucus-bounces@ietf.org Tue Feb 19 07:53:06 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7856F28C5B0; Tue, 19 Feb 2008 07:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKNpD0sOdRCe; Tue, 19 Feb 2008 07:53:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7751F28C44F; Tue, 19 Feb 2008 07:53:05 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C7828C44F for ; Tue, 19 Feb 2008 07:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLvxGV+1GMnZ for ; Tue, 19 Feb 2008 07:53:03 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id CB9193A6B36 for ; Tue, 19 Feb 2008 07:53:02 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28062176 for rucus@ietf.org; Tue, 19 Feb 2008 15:52:59 +0000 Mime-Version: 1.0 (Apple Message framework v753) To: rucus BoF Message-Id: References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FF6@mx1.office> From: Dan York Date: Tue, 19 Feb 2008 10:52:57 -0500 X-Mailer: Apple Mail (2.753) Subject: [Rucus] List of updated drafts for BOF? Fwd: Reading list for BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2088493218==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============2088493218== Content-Type: multipart/alternative; boundary=Apple-Mail-118--356605925 --Apple-Mail-118--356605925 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed With the deadline now passed for new drafts (but with the other deadline next Monday for updated drafts), can we get a consolidated list of all the relevant updated drafts related to RUCUS? Are there any others that we need to add to this list? I think we have now: -- new version for SPITSTOP draft (-01) http://tools.ietf.org/html/draft-niccolini-sipping-spitstop-01 -- new version of the spam score draft (-01) http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 -- new draft on spam score semantics (-00) http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam-score- semantics-00.txt -- new draft on SIP spam feedback (-00) http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 -- new draft on RUCUS problem statement (-00) http://www.ietf.org/internet-drafts/draft-schwartz-rucus-problem- statement-01.txt -- new draft of SIP scenarios similar to SPIT (-00) http://www.ietf.org/internet-drafts/draft-york-sipping-spit- similarity-scenarios-00.txt Along with other existing drafts: -- Framework for reducing unwanted communication http://www.ietf.org/internet-drafts/draft-tschofenig-sipping- framework-spit-reduction-02.txt -- CAPTCHA-based Robot Challenges for the Session Initiation Protocol (SIP) http://tools.ietf.org/rfcmarkup?doc=draft-tschofenig-sipping-captcha -- A Document Format for Expressing Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony http://tools.ietf.org/rfcmarkup?doc=draft-tschofenig-sipping-spit-policy and of course RFC 5039: http://tools.ietf.org/rfcmarkup?doc=rfc5039 Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-118--356605925 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
With the deadline now passed for new drafts (but with the other = deadline next Monday for updated drafts), can we get a consolidated list = of all the relevant updated drafts related to RUCUS?

Are there any others that = we need to add to this list? =A0

I think we have = now:

-- new version for SPITSTOP draft (-01)
-- new version of the spam score draft = (-01)
-- new draft on spam score semantics (-00)
-- new draft = on SIP spam feedback (-00)
-- new draft on RUCUS problem statement = (-00)
-- new draft = of SIP scenarios similar to SPIT (-00)
Along with other existing = drafts:

-- Framework = for reducing unwanted communication
-- = CAPTCHA-based Robot Challenges for the Session Initiation Protocol = (SIP)
-- A Document Format for = Expressing Authorization Policies to tackle Spam
and Unwanted Communication for Internet = Telephony=A0

and of course RFC = 5039:

=A0=A0http://tools.ietf.o= rg/rfcmarkup?doc=3Drfc5039

Regards,
Dan
=

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.




= --Apple-Mail-118--356605925-- --===============2088493218== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============2088493218==-- From rucus-bounces@ietf.org Tue Feb 19 08:07:44 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF6628C62B; Tue, 19 Feb 2008 08:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmFQsBEGPqVZ; Tue, 19 Feb 2008 08:07:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F17F3A6E16; Tue, 19 Feb 2008 08:07:43 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D9828C5E6 for ; Tue, 19 Feb 2008 08:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7maRyrp5Lbg for ; Tue, 19 Feb 2008 08:07:40 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 1B35D28C668 for ; Tue, 19 Feb 2008 08:06:59 -0800 (PST) Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m1JG4tIJ012727; Tue, 19 Feb 2008 17:04:55 +0100 Received: from [139.54.131.75] ([139.54.131.75]) by FRVELSBHS07.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 19 Feb 2008 17:06:55 +0100 Message-ID: <47BAFE9D.5060409@alcatel-lucent.fr> Date: Tue, 19 Feb 2008 17:06:53 +0100 From: Thomas Froment User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Dan York References: <5F6519BF2DE0404D99B7C75607FF76FF4D0FF6@mx1.office> In-Reply-To: X-OriginalArrivalTime: 19 Feb 2008 16:06:55.0165 (UTC) FILETIME=[727026D0:01C87311] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: rucus BoF Subject: Re: [Rucus] List of updated drafts for BOF? Fwd: Reading list for BoF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi, I will submit really soon in the repository an update of 'spit policies requirements':http://tools.ietf.org/html/draft-froment-sipping-spit-requirements which is the requirement document associated to http://www.ietf.org/internet-drafts/draft-tschofenig-sipping-framework-spit-reduction-02.txt Best regards, Thomas Dan York wrote: > With the deadline now passed for new drafts (but with the other > deadline next Monday for updated drafts), can we get a consolidated > list of all the relevant updated drafts related to RUCUS? > > Are there any others that we need to add to this list? > > I think we have now: > > -- new version for SPITSTOP draft (-01) > http://tools.ietf.org/html/draft-niccolini-sipping-spitstop-01 > -- new version of the spam score draft (-01) > http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 > -- new draft on spam score semantics (-00) > http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam-score-semantics-00.txt > -- new draft on SIP spam feedback (-00) > http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 > -- new draft on RUCUS problem statement (-00) > http://www.ietf.org/internet-drafts/draft-schwartz-rucus-problem-statement-01.txt > -- new draft of SIP scenarios similar to SPIT (-00) > http://www.ietf.org/internet-drafts/draft-york-sipping-spit-similarity-scenarios-00.txt > > Along with other existing drafts: > > -- Framework for reducing unwanted communication > http://www.ietf.org/internet-drafts/draft-tschofenig-sipping-framework-spit-reduction-02.txt > -- CAPTCHA-based Robot Challenges for the Session Initiation Protocol > (SIP) > http://tools.ietf.org/rfcmarkup?doc=draft-tschofenig-sipping-captcha > -- A Document Format for Expressing Authorization Policies to tackle Spam > and Unwanted Communication for Internet Telephony > http://tools.ietf.org/rfcmarkup?doc=draft-tschofenig-sipping-spit-policy > > and of course RFC 5039: > > http://tools.ietf.org/rfcmarkup?doc=rfc5039 > > Regards, > Dan > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 08:50:58 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF0228C615; Tue, 19 Feb 2008 08:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.158 X-Spam-Level: X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QqD6A-IxSuB; Tue, 19 Feb 2008 08:50:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F05128C58C; Tue, 19 Feb 2008 08:50:56 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344813A6821 for ; Tue, 19 Feb 2008 08:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzZNqE4iZLTx for ; Tue, 19 Feb 2008 08:50:54 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E81D328C58C for ; Tue, 19 Feb 2008 08:50:53 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id BAFDD2C01D460; Tue, 19 Feb 2008 17:50:50 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+tVIpHExuKF; Tue, 19 Feb 2008 17:50:50 +0100 (CET) Received: by smtp0.neclab.eu (Postfix, from userid 1001) id 9EB7F2C01D461; Tue, 19 Feb 2008 17:50:50 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 52C1B2C01D460; Tue, 19 Feb 2008 17:50:40 +0100 (CET) Received: from 10.1.1.104 ([10.1.1.104]) by mx1.office ([10.1.1.23]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Feb 2008 16:50:40 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 19 Feb 2008 17:51:09 +0100 From: Juergen Quittek To: Message-ID: Thread-Topic: Draft RUCUS charter Thread-Index: AchzF6A/3s7eS98KEdykKwAWy4a5Gw== Mime-version: 1.0 X-Sanitizer: This message has been sanitized! Cc: Signaling TO Prevent SPIT Subject: [Rucus] Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear all, I had a look at the draft charter that Hannes set up on his RUCUS web page and I think it is targeting the right direction. However, I suggest extending the scope and have attached a modified version of the draft charter below. My only major problem with the current version is that it fully builds on the recommendations given in RFC 5039, namely - Strong Identity - White Lists - Solve the Introduction Problem - Don't Wait Until It's Too Late I do not think that these approaches are wrong, but that they do not cover what I consider to be the most important issue in reducing SIP spam. Today, most of the spam email comes from bot-nets and recently email spammers started to send massively from compromized valid email accounts. I do not see why this would not become also the biggest source of SIP spam in the future. Consequently, we should address this issue when developing an architecture for reducing SIP spam in the RUCUS WG. The architecture should be general enough for covering also means that reduce SIP spam from bot nets and compromized accounts Whether or not to work on this problem is being discussed highly controversially in the IETF. But considering that the RUCUS BoF is targeted at establishing not a regular working group, but an RFC 5111 Exploratory Group, I do not think it would be appropriate to exclude such work from the beginning. It should rather be part of the exploratory work to find out whether or not reducing SIP spam from bot nets is a target worth to be attacked by the IETF. Below please find my suggestion for extending the charter. Main differences to the current draft are the new third paragraph (starting with "Strong identities ...") and some additions to the end of the fifth paragraph. Thanks, Juergen ==================== The Session Initiation Protocol (SIP) defines a system for user-to-user multimedia communications. Therefore, it is susceptible to unwanted communication attempts. RFC 5039 analyzes the problem of spam in SIP and examines various possible solutions that have been discussed for email and considers their applicability to SIP. RFC 5039 gives good, high-level recommendations regarding future work, namely * Strong Identity * White Lists * Solve the Introduction Problem * Don't Wait Until It's Too Late Strong identities and white lists will be essential in a well protected environment but do not solve the problem in the open Internet. In the open Internet compromised accounts and bot-nets are the major source of email spam today and expected to be the major source of SIP spam in the future. Among the many individual solution building blocks that are discussed in RFC 5039 (including content filtering, black lists, white lists, consent-based communication, reputation systems, address obfuscation, limited use addresses, turing tests, computational puzzles, payments at risk, circles of trust, and many others) there is no framework outlined how various mechanisms work together to produce a complete solution nor does the document attempt to offer a ranking to determine which solutions could form an initial set of candidate for subsequent standardization. This exploratory group chartered for one year aims to create a venue where discussions on unwanted communication in SIP can take place. The main goal of the group is to produce an architecture document that outlines the interworking between identified potential building blocks. The architecture will be general to cover a range of scenarios including well protected environment as well as the open Internet. The group will consider prior work on SIP identity and related techniques and will consult with privacy experts to deal with the legal aspects of filtering communication attempts. Out of the scope; -- PSTN replacement -- concrete algorithms for SIP spam prevention _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 10:58:09 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3DE28C6A1; Tue, 19 Feb 2008 10:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.263 X-Spam-Level: X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_27=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLYp1IZu8gao; Tue, 19 Feb 2008 10:58:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4768028C4F7; Tue, 19 Feb 2008 10:58:04 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0459828C5F4 for ; Tue, 19 Feb 2008 10:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk8a6Vxo-hnF for ; Tue, 19 Feb 2008 10:58:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 905283A6B20 for ; Tue, 19 Feb 2008 10:57:55 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2008 18:57:51 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp010) with SMTP; 19 Feb 2008 19:57:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18yiiYtmgUyMp+n3g0+gwCHDNCX/yRz0IfGuWEJyp q4rTcGdOGr+YrL Message-ID: <47BB26AB.8080708@gmx.net> Date: Tue, 19 Feb 2008 20:57:47 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Juergen, thanks for your feedback. The current charter proposal does not say indicate that - Strong Identity - White Lists - Solve the Introduction Problem - Don't Wait Until It's Too Late are the solution to the problem; it just indicates what RFC 5039 says. I do,however, agree with you that we should explicitly indicate that we want to explore different architectural approaches. Even though white lists are quite common in today's instant messaging world they are more or less unknown in the PSTN. The user's behavior will be quite important to understand with some of these different approaches. I agree that looking at botnets and similar mechanisms is useful. Still, I would avoid the term "open Internet" since it is somewhat fuzzy. Regarding your paragraph: " Strong identities and white lists will be essential in a well protected environment but do not solve the problem in the open Internet. In the open Internet compromised accounts and bot-nets are the major source of email spam today and expected to be the major source of SIP spam in the future. " We might need to ask the DKIM folks to better understand the current state of the art in email spam. For example: Are compromised accounts really a major source of email spam today? FROM: The architecture will be general to cover a range of scenarios including well protected environment as well as the open Internet. TO: The architectural investigations should cover different threat models, including those of compromised end hosts. You wrote: " Out of the scope; -- PSTN replacement -- concrete algorithms for SIP spam prevention " I agree with the second one but what exactly have you had in mind with PSTN replacement in this context? Ciao Hannes Juergen Quittek wrote: > Dear all, > > I had a look at the draft charter that Hannes set up on his RUCUS > web page and I think it is targeting the right direction. However, > I suggest extending the scope and have attached a modified version > of the draft charter below. > > My only major problem with the current version is that it fully > builds on the recommendations given in RFC 5039, namely > > - Strong Identity > - White Lists > - Solve the Introduction Problem > - Don't Wait Until It's Too Late > > I do not think that these approaches are wrong, but that they > do not cover what I consider to be the most important issue in > reducing SIP spam. > > Today, most of the spam email comes from bot-nets and recently > email spammers started to send massively from compromized > valid email accounts. I do not see why this would not become > also the biggest source of SIP spam in the future. > > Consequently, we should address this issue when developing an > architecture for reducing SIP spam in the RUCUS WG. The > architecture should be general enough for covering also means > that reduce SIP spam from bot nets and compromized accounts > > Whether or not to work on this problem is being discussed > highly controversially in the IETF. But considering that the > RUCUS BoF is targeted at establishing not a regular working > group, but an RFC 5111 Exploratory Group, I do not think it > would be appropriate to exclude such work from the beginning. > > It should rather be part of the exploratory work to find out > whether or not reducing SIP spam from bot nets is a target > worth to be attacked by the IETF. > > Below please find my suggestion for extending the charter. > Main differences to the current draft are the new third > paragraph (starting with "Strong identities ...") and some > additions to the end of the fifth paragraph. > > Thanks, > > Juergen > > > ==================== > > The Session Initiation Protocol (SIP) defines a system for > user-to-user multimedia communications. Therefore, it is > susceptible to unwanted communication attempts. RFC 5039 > analyzes the problem of spam in SIP and examines various > possible solutions that have been discussed for email and > considers their applicability to SIP. > > RFC 5039 gives good, high-level recommendations regarding > future work, namely > > * Strong Identity > * White Lists > * Solve the Introduction Problem > * Don't Wait Until It's Too Late > > Strong identities and white lists will be essential in a well > protected environment but do not solve the problem in the open > Internet. In the open Internet compromised accounts and bot-nets > are the major source of email spam today and expected to be the > major source of SIP spam in the future. > > Among the many individual solution building blocks that are > discussed in RFC 5039 (including content filtering, black lists, > white lists, consent-based communication, reputation systems, > address obfuscation, limited use addresses, turing tests, > computational puzzles, payments at risk, circles of trust, and > many others) there is no framework outlined how various > mechanisms work together to produce a complete solution nor > does the document attempt to offer a ranking to determine > which solutions could form an initial set of candidate for > subsequent standardization. > > This exploratory group chartered for one year aims to create a > venue where discussions on unwanted communication in SIP can > take place. The main goal of the group is to produce an > architecture document that outlines the interworking between > identified potential building blocks. The architecture will be > general to cover a range of scenarios including well protected > environment as well as the open Internet. > > The group will consider prior work on SIP identity and related > techniques and will consult with privacy experts to deal with > the legal aspects of filtering communication attempts. > > Out of the scope; > -- PSTN replacement > -- concrete algorithms for SIP spam prevention > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 11:16:20 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32BA73A6845; Tue, 19 Feb 2008 11:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.555, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awTDnqFMx+13; Tue, 19 Feb 2008 11:16:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E083A6A58; Tue, 19 Feb 2008 11:16:19 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90B23A6A58 for ; Tue, 19 Feb 2008 11:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPxchomvsLgY for ; Tue, 19 Feb 2008 11:16:18 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 09A4F3A6845 for ; Tue, 19 Feb 2008 11:16:18 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2008 11:16:15 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1JJGFW5002045; Tue, 19 Feb 2008 11:16:15 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1JJG9vn022629; Tue, 19 Feb 2008 19:16:14 GMT From: "Dan Wing" To: "'Martin Stiemerling'" , "'Otmar Lendl'" , References: <20080218201501.60A6A28C54D@core3.amsl.com><865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com><47BA843D.6050708@gmx.net><20080219093539.GA27334@bofh.priv.at> <059e01c872dc$dfaf5340$c4f0200a@cisco.com> <5F6519BF2DE0404D99B7C75607FF76FF4D10A0@mx1.office> Date: Tue, 19 Feb 2008 11:16:09 -0800 Message-ID: <079b01c8732b$e58efb40$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D10A0@mx1.office> Thread-Index: Achy2tTgxujlH2qgSYCAK1b3NcXf7gAATOrgAAXtLBAADevhMA== Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Rucus] SIP scenarios similar to SPIT -Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > ...which has been just reported today in German > networking/computer news. I have only the news report in > German as I didn't find any English version yet > (http://www.heise.de/newsticker/meldung/103711) Between my smattering of German that I still remember and some translation software, I got the gist of the attack. > The report basically points out that email spammers have just > climbed the brarrier of white lists and reputation systems. > They are hacking in email accounts of regular users and use > their accounts to send spam to others. The user's SMTP AUTH password is stored somewhere on their system (inside their Outlook, Thunderbird, Outlook Express, Eudora, or mail.app configuration). So even a non-privileged application running on the same system as the same user can probably get access to that password. SIP would share the same weakness. -d _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 11:21:36 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D650A3A6B6A; Tue, 19 Feb 2008 11:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yXWGUVaG3Kr; Tue, 19 Feb 2008 11:21:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52AA73A6B30; Tue, 19 Feb 2008 11:21:32 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CE23A6B22 for ; Tue, 19 Feb 2008 11:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZcA9BYrLa5W for ; Tue, 19 Feb 2008 11:21:28 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 399273A6A58 for ; Tue, 19 Feb 2008 11:21:28 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28066043; Tue, 19 Feb 2008 19:21:24 +0000 In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D10CF@mx1.office> References: <20080218201501.60A6A28C54D@core3.amsl.com><865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com><47BA843D.6050708@gmx.net> <20080219093539.GA27334@bofh.priv.at> <0B761124-2C2F-4B92-8A9A-5301C736BE32@voxeo.com> <5F6519BF2DE0404D99B7C75607FF76FF4D10CF@mx1.office> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <90F50B75-7AF6-466D-8AC0-A0A624C823E0@voxeo.com> From: Dan York Date: Tue, 19 Feb 2008 14:21:21 -0500 To: Saverio Niccolini X-Mailer: Apple Mail (2.753) Cc: rucus BoF Subject: [Rucus] Botnets... Re: SIP scenarios similar to SPIT - Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1339574113==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1339574113== Content-Type: multipart/alternative; boundary=Apple-Mail-125--344101219 --Apple-Mail-125--344101219 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Saverio, I absolutely agree that we need to be concerned about botnets. They absolutely need to be part of our thinking in terms of a larger architecture for addressing SPIT. The point I was trying to make was that I personally don't want to see RUCUS turn into a "how do we deal with SIP botnets" forum and in so doing we get caught up in that and lose sight of threats that might be closer at hand. To put it another way, I think we have to realize that botnets are out on the horizon, and we need to need to take those into account as we design our architecture, but there's probably a more real threat *today* from someone who installs Asterisk, downloads the "SPITTER" tool, sucks down a database via ENUM and starts making calls. Ultimately we have to address both issues (the script-kiddie with SPITTER and the serious botnet) and we need to aim to arrive at an architecture that lets us address the full spectrum. (Whether or not that is achievable in an "architecture" is, of course, an open question.) Regards, Dan On Feb 19, 2008, at 8:52 AM, Saverio Niccolini wrote: >> I don't know that we need to be hugely concerned about >> botnets in your near-term thinking about combatting SPIT, but >> I do agree that any larger architecture we look at should >> consider the fact that massively distributed "attacks" of >> voice spam by botnets could at some point become a reality. >> (and could indeed look like some of the scenarios I outlined >> in my document) > > I think we do need to be concerned about bot-nets. They are the main > source of email spam and they are the reason why many of us agree that > white list and reputation system are not enough for fighting SPIT. > > Saverio > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-125--344101219 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Saverio,

I = absolutely agree that we need to be concerned about botnets. =A0 They = absolutely need to be part of our thinking in terms of a larger = architecture for addressing SPIT.

The point I was trying to = make was that I personally don't want to see RUCUS turn into a "how do = we deal with SIP botnets" forum and in so doing we get caught up in that = and lose sight of threats that might be closer at hand. =A0To put it = another way, I think we have to realize that botnets are out on the = horizon, and we need to need to take those into account as we design our = architecture, but there's probably a more real threat *today* from = someone who installs Asterisk, downloads the "SPITTER" tool, sucks down = a database via ENUM and starts making calls.

Ultimately we have to = address both issues (the script-kiddie with SPITTER and the serious = botnet) and we need to aim to arrive at an architecture that lets us = address the full spectrum. (Whether or not that is achievable in an = "architecture" is, of course, an open question.)

Regards,
Dan
=

On Feb 19, 2008, at 8:52 AM, Saverio Niccolini = wrote:

I don't know = that we need to be hugely concerned about=A0
botnets = in your near-term thinking about combatting SPIT, but=A0
I do = agree that any larger architecture we look at should=A0
consider = the fact that massively distributed "attacks" of=A0
voice = spam by botnets could at some point become a reality. =A0
(and = could indeed look like some of the scenarios I outlined=A0
in my = document)

I think we do need to be = concerned about bot-nets. They are the main
source = of email spam and they are the reason why many of us agree = that
white list and reputation system = are not enough for fighting SPIT.

Saverio

Dr. Saverio = Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research = Division =
Kurfuerstenanlage 36, D-69115 = Heidelberg
Tel. =A0 =A0 +49 (0)6221 = 4342-118
Fax: =A0 =A0 +49 (0)6221 = 4342-155
e-mail:=A0 saverio.niccolini@nw.neclab= .eu <-- !!! NEW ADDRESS !!!
NEC Europe = Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England = 2832014
Rucus mailing list

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-125--344101219-- --===============1339574113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1339574113==-- From rucus-bounces@ietf.org Tue Feb 19 11:29:41 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F613A6E0F; Tue, 19 Feb 2008 11:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMCLCVTnnqeI; Tue, 19 Feb 2008 11:29:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5B23A692B; Tue, 19 Feb 2008 11:29:40 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD99B3A68A2 for ; Tue, 19 Feb 2008 11:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mQpTrh55ngQ for ; Tue, 19 Feb 2008 11:29:38 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 78A903A6B40 for ; Tue, 19 Feb 2008 11:29:38 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 8FA642C000357; Tue, 19 Feb 2008 20:29:35 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezOeOZPVsFYT; Tue, 19 Feb 2008 20:29:35 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 7190F2C000355; Tue, 19 Feb 2008 20:29:25 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 20:29:24 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D1127@mx1.office> In-Reply-To: <90F50B75-7AF6-466D-8AC0-A0A624C823E0@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Botnets... Re: [Rucus] SIP scenarios similar to SPIT - Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt Thread-Index: AchzLKSIZAPXFQcJQxyCJjTThggFuwAAHZJA References: <20080218201501.60A6A28C54D@core3.amsl.com><865E47D9-EB0F-4C92-8430-8748D5B85FA1@voxeo.com><47BA843D.6050708@gmx.net> <20080219093539.GA27334@bofh.priv.at> <0B761124-2C2F-4B92-8A9A-5301C736BE32@voxeo.com> <5F6519BF2DE0404D99B7C75607FF76FF4D10CF@mx1.office> <90F50B75-7AF6-466D-8AC0-A0A624C823E0@voxeo.com> From: "Saverio Niccolini" To: "Dan York" Cc: rucus BoF Subject: Re: [Rucus] Botnets... Re: SIP scenarios similar to SPIT - Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dan, I would be in principle fine with the wording: "The architectural investigations should cover different threat models, including those of compromised end hosts." (where for compromised end-host we basically say bot-nets installed on a legitimate host) And also: "The main goal of the group is to produce an architecture document that outlines the interworking between identified potential building blocks" where some of these building blocks take into account how to REDUCE unwanted communications even in the case of compomised end hosts. Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: Dan York [mailto:dyork@voxeo.com] > Sent: Tuesday, February 19, 2008 8:21 PM > To: Saverio Niccolini > Cc: rucus BoF > Subject: Botnets... Re: [Rucus] SIP scenarios similar to SPIT > - Fwd:I-D Action:draft-york-sipping-spit-similarity-scenarios-00.txt > > Saverio, > > I absolutely agree that we need to be concerned about > botnets. They absolutely need to be part of our thinking in > terms of a larger architecture for addressing SPIT. > > The point I was trying to make was that I personally don't > want to see RUCUS turn into a "how do we deal with SIP > botnets" forum and in so doing we get caught up in that and > lose sight of threats that might be closer at hand. To put > it another way, I think we have to realize that botnets are > out on the horizon, and we need to need to take those into > account as we design our architecture, but there's probably a > more real threat *today* from someone who installs Asterisk, > downloads the "SPITTER" tool, sucks down a database via ENUM > and starts making calls. > > Ultimately we have to address both issues (the script-kiddie > with SPITTER and the serious botnet) and we need to aim to > arrive at an architecture that lets us address the full > spectrum. (Whether or not that is achievable in an > "architecture" is, of course, an open question.) > > Regards, > Dan > > On Feb 19, 2008, at 8:52 AM, Saverio Niccolini wrote: > > > I don't know that we need to be hugely concerned about > botnets in your near-term thinking about > combatting SPIT, but > I do agree that any larger architecture we look > at should > consider the fact that massively distributed > "attacks" of > voice spam by botnets could at some point > become a reality. > (and could indeed look like some of the > scenarios I outlined > in my document) > > > I think we do need to be concerned about bot-nets. They > are the main > source of email spam and they are the reason why many > of us agree that > white list and reputation system are not enough for > fighting SPIT. > > Saverio > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 11:31:22 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFAF128C675; Tue, 19 Feb 2008 11:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpynKQ06CH1r; Tue, 19 Feb 2008 11:31:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E1128C5F4; Tue, 19 Feb 2008 11:31:21 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B1A28C53E for ; Tue, 19 Feb 2008 11:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7BrN-2Y7mGg for ; Tue, 19 Feb 2008 11:31:19 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3F4F928C4F7 for ; Tue, 19 Feb 2008 11:31:19 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4C17B2C000357; Tue, 19 Feb 2008 20:31:16 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGWlaCYDH22G; Tue, 19 Feb 2008 20:31:16 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 39ABB2C000355; Tue, 19 Feb 2008 20:31:06 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Feb 2008 20:31:05 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D1128@mx1.office> In-Reply-To: <47BB26AB.8080708@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Draft RUCUS charter Thread-Index: AchzKXm4I0whMHLURh+ClXlef4kD7AABFCTQ References: <47BB26AB.8080708@gmx.net> From: "Saverio Niccolini" To: , "Juergen Quittek" Cc: rucus@ietf.org Subject: Re: [Rucus] Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > Regarding your paragraph: > " > Strong identities and white lists will be essential in a well > protected environment but do not solve the problem in the > open Internet. In the open Internet compromised accounts and > bot-nets are the major source of email spam today and > expected to be the major source of SIP spam in the future. > " > > We might need to ask the DKIM folks to better understand the > current state of the art in email spam. For example: Are > compromised accounts really a major source of email spam today? Compromised hosts are a source of spam today: http://www.heise.de/newsticker/meldung/103711 the majority of email spam is coming from botnets: http://www.marketwire.com/mw/release.do?id=817241 Thus we can not ignore this threat in RUCUS. Cheers, Saverio _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 12:23:49 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F7828C530; Tue, 19 Feb 2008 12:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89m-FKGDb75C; Tue, 19 Feb 2008 12:23:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5212228C55E; Tue, 19 Feb 2008 12:23:48 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0518A28C55E for ; Tue, 19 Feb 2008 12:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9I2gYiJjQQq for ; Tue, 19 Feb 2008 12:23:46 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 12D6B28C530 for ; Tue, 19 Feb 2008 12:23:45 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28067770; Tue, 19 Feb 2008 20:23:41 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> From: Dan York Date: Tue, 19 Feb 2008 15:23:37 -0500 To: Juergen Quittek X-Mailer: Apple Mail (2.753) Cc: rucus@ietf.org, Signaling TO Prevent SPIT Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2120982027==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============2120982027== Content-Type: multipart/alternative; boundary=Apple-Mail-127--340365375 --Apple-Mail-127--340365375 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Juergen (and Saverio and others), I appreciate the point you are raising here. My interest and passion are in networking, communication and security. To me, botnets are both incredibly fascinating and incredibly terrifying. I agree with you that botnets very certainly may be the biggest source of SIP spam in the future. Here's my problem: We have to crawl before we can walk and before we can run. Let's say that this is the (incredibly simplistic view of the) evolution of email spam: 1. Someone figures out that they can send advertisements to a range of email addresses they have collected. 2. Someone realizes that they can add those addresses to a "mailing list" to easily send to a large number of addresses. 3. Tools are developed that automate the collection of addresses and the sending out of messages. 4. At a certain time, there are enough people using email out there that this whole area of email advertising is a huge financial marketplace. Companies/entities set up server farms to just send out tons of email messages. (Defenders blacklist those servers.) 5. Those "servers" get distributed into massive botnets and are then able to avoid blacklisting, etc. I have absolutely no doubt that SIP spam will unfortunately follow the exact same trajectory. We're already seeing the tools to automate SPIT (here's one: http://www.hackingvoip.com/tools/spitter.tar.gz ). At some point we will hit my #4 when there are enough people using SIP *with publicly accessible SIP addresses* that it becomes financially lucrative enough for the larger automation to occur - and following on the heels of that will be the botnets. It will happen. To me it's not a question of IF but rather WHEN. Right now, though, we're still in my steps 1-3 as people start to get SIP endpoints and realize how they can abuse them. My concern about adding the focus on botnets into RUCUS is the fact that we can easily get distracted into looking at how to solve bigger issues and not get done the smaller issues that we can perhaps address today. Let's face it, probably all of us on this list would be categorized as early adopters who like to explore cutting edge technologies. We like to chase bright shiny objects and what is new and sexy and interesting. Let's say that you have a choice at the next IETF to listen to either: 1. a presentation on a SIP header to pass a "spam score" value between a SIP proxy and a UA; or 2. a presentation about SIP botnets, how they are constructed and the threats they pose. I would expect that probably 90% of us would choose the botnet talk. (No disrespect intended to the spam-score folks, just using an example.) The reality, though, is that the spam score discussion might be far more useful in moving us toward solutions that will help us with the people abusing SIP systems today. I don't want to wake up some day and find out that while we've been having a ton of discussions about botnets, some idiot meanwhile is repeatedly connecting to my SIP server and pumping our voicemail system full of SPIT. Maybe it's crazy on my part, but I want to see RUCUS have a charter that results in an achievable plan and architecture. Yes, we should consider botnets as a potential source of SIP spam and, yes, the potential existence of SIP botnets should be included in our thinking about an architecture to address SIP spam (so that any architecture we come up with does not discount dealing with botnets). But I also think we need to stay focused on what we can do now about the threats that are out there today (before it's too late). Let's crawl first, then walk, then run. My 2 cents, Dan On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: > Today, most of the spam email comes from bot-nets and recently > email spammers started to send massively from compromized > valid email accounts. I do not see why this would not become > also the biggest source of SIP spam in the future. > > Consequently, we should address this issue when developing an > architecture for reducing SIP spam in the RUCUS WG. The > architecture should be general enough for covering also means > that reduce SIP spam from bot nets and compromized accounts > > Whether or not to work on this problem is being discussed > highly controversially in the IETF. But considering that the > RUCUS BoF is targeted at establishing not a regular working > group, but an RFC 5111 Exploratory Group, I do not think it > would be appropriate to exclude such work from the beginning. > > It should rather be part of the exploratory work to find out > whether or not reducing SIP spam from bot nets is a target > worth to be attacked by the IETF. -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-127--340365375 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Juergen (and Saverio and others),

I appreciate the point you = are raising here. =A0My interest and passion are in networking, = communication and security. =A0To me, botnets are both incredibly = fascinating and incredibly terrifying. =A0I agree with you that botnets = very certainly may be the biggest source of SIP spam in the = future.

Here's= my problem:

=A0=A0 =A0 We have to = crawl before we can walk and before we can run.

Let's say that this is the = (incredibly simplistic view of the) evolution of email = spam:

1. = Someone figures out that they can send advertisements to a range of = email addresses they have collected.
2. Someone realizes that = they can add those addresses to a "mailing list" to easily send to a = large number of addresses.
3. Tools are developed that = automate the collection of addresses and the sending out of = messages.
4. At a certain time, there are enough people using = email out there that this whole area of email advertising is a huge = financial marketplace. Companies/entities set up server farms to just = send out tons of email messages. (Defenders blacklist those = servers.)
5. Those "servers" get distributed into massive = botnets and are then able to avoid blacklisting, etc.

I have absolutely no doubt = that SIP spam will unfortunately follow the exact same trajectory. We're = already seeing the tools to automate SPIT (here's one:=A0http://www.hackin= gvoip.com/tools/spitter.tar.gz ). =A0At some point we will hit my #4 = when there are enough people using SIP *with publicly accessible SIP = addresses* that it becomes financially lucrative enough for the larger = automation to occur - and following on the heels of that will be the = botnets. =A0It will happen. =A0To me it's not a question of IF but = rather WHEN.

Right now, though, we're = still in my steps 1-3 as people start to get SIP endpoints and realize = how they can abuse them.

My concern about adding = the focus on botnets into RUCUS is the fact that we can easily get = distracted into looking at how to solve bigger issues and not get done = the smaller issues that we can perhaps address today.

Let's face it, probably = all of us on this list would be categorized as early adopters who like = to explore cutting edge technologies. =A0We like to chase bright shiny = objects and what is new and sexy and interesting. =A0Let's say that you = have a choice at the next IETF to listen to either:
1. a = presentation on a SIP header to pass a "spam score" value between a SIP = proxy and a UA; or
2. a presentation about SIP botnets, how = they are constructed and the threats they pose.
I would expect = that probably 90% of us would choose the botnet talk. (No disrespect = intended to the spam-score folks, just using an example.) The reality, = though, is that the spam score discussion might be far more useful in = moving us toward solutions that will help us with the people abusing SIP = systems today. =A0I don't want to wake up some day and find out that = while we've been having a ton of discussions about botnets, some idiot = meanwhile is repeatedly connecting to my SIP server and pumping our = voicemail system full of SPIT.

Maybe it's crazy on my = part, but I want to see RUCUS have a charter that results in an = achievable plan and architecture.

Yes, we should consider = botnets as a potential source of SIP spam and, yes, the potential = existence of SIP botnets should be included in our thinking about an = architecture to address SIP spam (so that any architecture we come up = with does not discount dealing with botnets). =A0But I also think we = need to stay focused on what we can do now about the threats that are = out there today (before it's too late). =A0=A0Let's crawl first, then = walk, then run.

My 2 = cents,
Dan

On Feb 19, 2008, at = 11:51 AM, Juergen Quittek wrote:
Today, most of the spam email = comes from bot-nets and recently
email = spammers started to send massively from compromized
valid email accounts.=A0 I do not see why this would = not become
also the biggest source of SIP = spam in the future.
Consequently, we should address = this issue when developing an
architecture = for reducing SIP spam in the RUCUS WG.=A0 The
architecture should be general enough for covering = also means
that reduce SIP spam from bot = nets and compromized accounts

Whether or not to work on this = problem is being discussed
highly = controversially in the IETF. But considering that the
RUCUS BoF is targeted at establishing not a regular = working
group, but an RFC 5111 = Exploratory Group, I do not think it
would be = appropriate to exclude such work from the beginning.

It = should rather be part of the exploratory work to find out
whether or not reducing SIP spam from bot nets is a = target
worth to be attacked by the = IETF.

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-127--340365375-- --===============2120982027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============2120982027==-- From rucus-bounces@ietf.org Tue Feb 19 12:25:16 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF7428C589; Tue, 19 Feb 2008 12:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf0yG-QRgEUT; Tue, 19 Feb 2008 12:25:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CD1E3A6B61; Tue, 19 Feb 2008 12:25:16 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B6B28C0FE for ; Tue, 19 Feb 2008 12:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AWSI1uDZnAQ for ; Tue, 19 Feb 2008 12:25:13 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1E7D93A6AC5 for ; Tue, 19 Feb 2008 12:25:12 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2008 20:25:08 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp023) with SMTP; 19 Feb 2008 21:25:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19nDlgJU2hnvvrox9084hH7OLdSsCugNRiTnOrbTN Q3bc5GS/jXSbdJ Message-ID: <47BB3B22.905@gmx.net> Date: Tue, 19 Feb 2008 22:25:06 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Saverio Niccolini References: <47BB26AB.8080708@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF4D1128@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D1128@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org, Juergen Quittek Subject: Re: [Rucus] Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Saverio, Saverio Niccolini wrote: >> Regarding your paragraph: >> " >> Strong identities and white lists will be essential in a well >> protected environment but do not solve the problem in the >> open Internet. In the open Internet compromised accounts and >> bot-nets are the major source of email spam today and >> expected to be the major source of SIP spam in the future. >> " >> >> We might need to ask the DKIM folks to better understand the >> current state of the art in email spam. For example: Are >> compromised accounts really a major source of email spam today? >> > > Compromised hosts are a source of spam today: > http://www.heise.de/newsticker/meldung/103711 > > the majority of email spam is coming from botnets: > http://www.marketwire.com/mw/release.do?id=817241 > > Thus we can not ignore this threat in RUCUS. > > I am certainly not ignoring this aspect. I want to make sure that we capture the current state-of-the-art correctly. Ciao Hannes > Cheers, > Saverio > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 19 14:09:33 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A823A6AC5; Tue, 19 Feb 2008 14:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_27=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybiTefHXWhFC; Tue, 19 Feb 2008 14:09:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF123A6B2B; Tue, 19 Feb 2008 14:09:31 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9508D3A6ABC for ; Tue, 19 Feb 2008 14:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9t4H+S0pQsq for ; Tue, 19 Feb 2008 14:09:29 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0D2053A67E4 for ; Tue, 19 Feb 2008 14:09:29 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 0F0932C002B4A; Tue, 19 Feb 2008 23:09:26 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQL2h+Vqj7Hg; Tue, 19 Feb 2008 23:09:25 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id E3D0B2C000357; Tue, 19 Feb 2008 23:09:15 +0100 (CET) Received: from 10.7.0.54 ([10.7.0.54]) by mx1.office ([10.1.1.23]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Feb 2008 22:09:16 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 19 Feb 2008 23:09:44 +0100 From: Juergen Quittek To: Message-ID: Thread-Topic: [Rucus] Draft RUCUS charter Thread-Index: AchzRCGsYAuvQN83EdykKwAWy4a5Gw== In-Reply-To: <47BB26AB.8080708@gmx.net> Mime-version: 1.0 Cc: rucus@ietf.org Subject: Re: [Rucus] Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Hannes, On 19.02.2008 19:57 Uhr "Hannes Tschofenig" wrote: > Hi Juergen, > > thanks for your feedback. > > The current charter proposal does not say indicate that > > - Strong Identity > - White Lists > - Solve the Introduction Problem > - Don't Wait Until It's Too Late > > are the solution to the problem; it just indicates what RFC 5039 says. > > I do,however, agree with you that we should explicitly indicate that we > want to explore different architectural approaches. Even though white > lists are quite common in today's instant messaging world they are more > or less unknown in the PSTN. The user's behavior will be quite important > to understand with some of these different approaches. I fully agree. This is an important study item. > I agree that looking at botnets and similar mechanisms is useful. Still, > I would avoid the term "open Internet" since it is somewhat fuzzy. Yes, there may be better terms. I just would like to express, that outside of well protected environment, there may be a need for means beyond strong identities and white lists. And these should be investigated by the RUCUS EG. > Regarding your paragraph: > " > Strong identities and white lists will be essential in a well > protected environment but do not solve the problem in the open > Internet. In the open Internet compromised accounts and bot-nets > are the major source of email spam today and expected to be the > major source of SIP spam in the future. > " > > We might need to ask the DKIM folks to better understand the current > state of the art in email spam. For example: Are compromised accounts > really a major source of email spam today? Well, using 'compromized hosts' as you do below would be fine. We can investigate the relevance of compromized accounts when RUCUS is established. (In Germany leading IT journals reported today that compromized accounts are becoming relevant for email spam.) > FROM: > The architecture will be > general to cover a range of scenarios including well protected > environment as well as the open Internet. > > > TO: > The architectural investigations should cover different threat > models, including those of compromised end hosts. That's fine and probably less controversial. > You wrote: > " > Out of the scope; > > -- PSTN replacement > -- concrete algorithms for SIP spam prevention > " > > I agree with the second one but what exactly have you had in mind with > PSTN replacement in this context? Sorry, these were my notes what to exclude. But it is not yet elaborated. > Ciao > Hannes Thanks, Juergen > > Juergen Quittek wrote: >> Dear all, >> >> I had a look at the draft charter that Hannes set up on his RUCUS >> web page and I think it is targeting the right direction. However, >> I suggest extending the scope and have attached a modified version >> of the draft charter below. >> >> My only major problem with the current version is that it fully >> builds on the recommendations given in RFC 5039, namely >> >> - Strong Identity >> - White Lists >> - Solve the Introduction Problem >> - Don't Wait Until It's Too Late >> >> I do not think that these approaches are wrong, but that they >> do not cover what I consider to be the most important issue in >> reducing SIP spam. >> >> Today, most of the spam email comes from bot-nets and recently >> email spammers started to send massively from compromized >> valid email accounts. I do not see why this would not become >> also the biggest source of SIP spam in the future. >> >> Consequently, we should address this issue when developing an >> architecture for reducing SIP spam in the RUCUS WG. The >> architecture should be general enough for covering also means >> that reduce SIP spam from bot nets and compromized accounts >> >> Whether or not to work on this problem is being discussed >> highly controversially in the IETF. But considering that the >> RUCUS BoF is targeted at establishing not a regular working >> group, but an RFC 5111 Exploratory Group, I do not think it >> would be appropriate to exclude such work from the beginning. >> >> It should rather be part of the exploratory work to find out >> whether or not reducing SIP spam from bot nets is a target >> worth to be attacked by the IETF. >> >> Below please find my suggestion for extending the charter. >> Main differences to the current draft are the new third >> paragraph (starting with "Strong identities ...") and some >> additions to the end of the fifth paragraph. >> >> Thanks, >> >> Juergen >> >> >> ==================== >> >> The Session Initiation Protocol (SIP) defines a system for >> user-to-user multimedia communications. Therefore, it is >> susceptible to unwanted communication attempts. RFC 5039 >> analyzes the problem of spam in SIP and examines various >> possible solutions that have been discussed for email and >> considers their applicability to SIP. >> >> RFC 5039 gives good, high-level recommendations regarding >> future work, namely >> >> * Strong Identity >> * White Lists >> * Solve the Introduction Problem >> * Don't Wait Until It's Too Late >> >> Strong identities and white lists will be essential in a well >> protected environment but do not solve the problem in the open >> Internet. In the open Internet compromised accounts and bot-nets >> are the major source of email spam today and expected to be the >> major source of SIP spam in the future. >> >> Among the many individual solution building blocks that are >> discussed in RFC 5039 (including content filtering, black lists, >> white lists, consent-based communication, reputation systems, >> address obfuscation, limited use addresses, turing tests, >> computational puzzles, payments at risk, circles of trust, and >> many others) there is no framework outlined how various >> mechanisms work together to produce a complete solution nor >> does the document attempt to offer a ranking to determine >> which solutions could form an initial set of candidate for >> subsequent standardization. >> >> This exploratory group chartered for one year aims to create a >> venue where discussions on unwanted communication in SIP can >> take place. The main goal of the group is to produce an >> architecture document that outlines the interworking between >> identified potential building blocks. The architecture will be >> general to cover a range of scenarios including well protected >> environment as well as the open Internet. >> >> The group will consider prior work on SIP identity and related >> techniques and will consult with privacy experts to deal with >> the legal aspects of filtering communication attempts. >> >> Out of the scope; >> -- PSTN replacement >> -- concrete algorithms for SIP spam prevention >> >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> http://www.ietf.org/mailman/listinfo/rucus >> > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Feb 20 00:38:05 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07E93A6E2E; Wed, 20 Feb 2008 00:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLRQvz4VG9lC; Wed, 20 Feb 2008 00:37:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42473A68BF; Wed, 20 Feb 2008 00:37:58 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DFF63A68BF for ; Wed, 20 Feb 2008 00:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0lQawnO-S6q for ; Wed, 20 Feb 2008 00:37:47 -0800 (PST) Received: from mailgate.gfi.com (mailgate.gfi.com [80.85.100.4]) by core3.amsl.com (Postfix) with ESMTP id 1C3B53A6960 for ; Wed, 20 Feb 2008 00:37:46 -0800 (PST) Received: from gfimailgate.gfimalta.com ([192.168.31.8]) by mailgate.gfi.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 09:36:18 +0100 Received: from MAILFAXSRV.gfimalta.com ([172.16.130.5]) by gfimailgate.gfimalta.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 09:37:42 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 09:37:40 +0100 Message-ID: <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Botnets, take 2... Re: Draft RUCUS charter thread-index: AchzNYi17re5qV7XSzGrJu/DO4SMcwAYq8jA References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> From: "Brian Azzopardi" To: "Dan York" ,"Juergen Quittek" X-OriginalArrivalTime: 20 Feb 2008 08:37:42.0679 (UTC) FILETIME=[DBEAEA70:01C8739B] Cc: rucus@ietf.org, Signaling TO Prevent SPIT Subject: Re: [Rucus] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1148480821==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org This is a multi-part message in MIME format. --===============1148480821== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8739B.DA973F1D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8739B.DA973F1D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan, =20 I am afraid that we may have to hit the ground running. Email spam is already a big industry with well established operators. Spewing out SPIT instead of email spam is just another 'product' for them. Only amateur SPITers will use spitter and other such tools - the professional ones already have the infrastructure in place and they'd be irrational not to reuse it for SPIT - they will just short-circuit to your step 5. We do need to think deeply about botnets - they are the principal means of sending spam and have been for at least the last 2 years. =20 Regards, =20 Brian Azzopardi - Senior Business Analyst GFI Software - www.gfi.com =20 =20 =20 From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of Dan York Sent: 19 February 2008 21:24 To: Juergen Quittek Cc: rucus@ietf.org; Signaling TO Prevent SPIT Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter =20 Juergen (and Saverio and others), =20 I appreciate the point you are raising here. My interest and passion are in networking, communication and security. To me, botnets are both incredibly fascinating and incredibly terrifying. I agree with you that botnets very certainly may be the biggest source of SIP spam in the future. =20 Here's my problem: =20 We have to crawl before we can walk and before we can run. =20 Let's say that this is the (incredibly simplistic view of the) evolution of email spam: =20 1. Someone figures out that they can send advertisements to a range of email addresses they have collected. 2. Someone realizes that they can add those addresses to a "mailing list" to easily send to a large number of addresses. 3. Tools are developed that automate the collection of addresses and the sending out of messages. 4. At a certain time, there are enough people using email out there that this whole area of email advertising is a huge financial marketplace. Companies/entities set up server farms to just send out tons of email messages. (Defenders blacklist those servers.) 5. Those "servers" get distributed into massive botnets and are then able to avoid blacklisting, etc. =20 I have absolutely no doubt that SIP spam will unfortunately follow the exact same trajectory. We're already seeing the tools to automate SPIT (here's one: http://www.hackingvoip.com/tools/spitter.tar.gz ). At some point we will hit my #4 when there are enough people using SIP *with publicly accessible SIP addresses* that it becomes financially lucrative enough for the larger automation to occur - and following on the heels of that will be the botnets. It will happen. To me it's not a question of IF but rather WHEN. =20 Right now, though, we're still in my steps 1-3 as people start to get SIP endpoints and realize how they can abuse them. =20 My concern about adding the focus on botnets into RUCUS is the fact that we can easily get distracted into looking at how to solve bigger issues and not get done the smaller issues that we can perhaps address today. =20 Let's face it, probably all of us on this list would be categorized as early adopters who like to explore cutting edge technologies. We like to chase bright shiny objects and what is new and sexy and interesting. Let's say that you have a choice at the next IETF to listen to either: 1. a presentation on a SIP header to pass a "spam score" value between a SIP proxy and a UA; or 2. a presentation about SIP botnets, how they are constructed and the threats they pose. I would expect that probably 90% of us would choose the botnet talk. (No disrespect intended to the spam-score folks, just using an example.) The reality, though, is that the spam score discussion might be far more useful in moving us toward solutions that will help us with the people abusing SIP systems today. I don't want to wake up some day and find out that while we've been having a ton of discussions about botnets, some idiot meanwhile is repeatedly connecting to my SIP server and pumping our voicemail system full of SPIT. =20 Maybe it's crazy on my part, but I want to see RUCUS have a charter that results in an achievable plan and architecture. =20 Yes, we should consider botnets as a potential source of SIP spam and, yes, the potential existence of SIP botnets should be included in our thinking about an architecture to address SIP spam (so that any architecture we come up with does not discount dealing with botnets). But I also think we need to stay focused on what we can do now about the threats that are out there today (before it's too late). Let's crawl first, then walk, then run. =20 My 2 cents, Dan =20 On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: Today, most of the spam email comes from bot-nets and recently email spammers started to send massively from compromized valid email accounts. I do not see why this would not become also the biggest source of SIP spam in the future. =20 Consequently, we should address this issue when developing an architecture for reducing SIP spam in the RUCUS WG. The architecture should be general enough for covering also means that reduce SIP spam from bot nets and compromized accounts =20 Whether or not to work on this problem is being discussed highly controversially in the IETF. But considering that the RUCUS BoF is targeted at establishing not a regular working group, but an RFC 5111 Exploratory Group, I do not think it would be appropriate to exclude such work from the beginning. =20 It should rather be part of the exploratory work to find out whether or not reducing SIP spam from bot nets is a target worth to be attacked by the IETF. =20 --=20 Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com =20 Bring your web applications to the phone. Find out how at http://evolution.voxeo.com =20 =20 =20 DISCLAIMER The information contained in this electronic mail may be confidential or legally privileged. It is for the intended recipient(s) only. Should you receive this message in error, please notify the sender by replying to this mail. Unless expressly stated, opinions in this message are those of the individual sender and not of GFI. Unauthorized use of the contents is strictly prohibited. While all care has been taken, GFI is not responsible for the integrity of the contents of this electronic mail and any attachments included within. =20 This mail was checked for viruses by GFI MailSecurity.=20 GFI also develops anti-spam software (GFI MailEssentials), a fax server = (GFI FAXmaker), and network security and management software (GFI = LANguard) - www.gfi.com=20 ------_=_NextPart_001_01C8739B.DA973F1D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan,

 

I am afraid that we may have to hit the ground running. = Email spam is already a big industry with well established operators. Spewing = out SPIT instead of email spam is just another ‘product’ for = them. Only amateur SPITers will use spitter and other such tools – the = professional ones already have the infrastructure in place and they’d be = irrational not to reuse it for SPIT – they will just short-circuit to your = step 5.  We do need to think deeply about botnets – they are the principal = means of sending spam and have been for at least the last 2 = years.

 

Regards,

 

Brian Azzopardi - Senior Business = Analyst

GFI Software - www.gfi.com

 

 

From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of Dan York
Sent: 19 February 2008 21:24
To: Juergen Quittek
Cc: rucus@ietf.org; Signaling TO Prevent SPIT
Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS = charter

 

Juergen (and Saverio and others),

 

I appreciate the point you are raising here. =  My interest and passion are in networking, communication and security. =  To me, botnets are both incredibly fascinating and incredibly terrifying. =  I agree with you that botnets very certainly may be the biggest source of = SIP spam in the future.

 

Here's my problem:

 

     We have to crawl before we can = walk and before we can run.

 

Let's say that this is the (incredibly simplistic = view of the) evolution of email spam:

 

1. Someone figures out that they can send = advertisements to a range of email addresses they have collected.

2. Someone realizes that they can add those = addresses to a "mailing list" to easily send to a large number of = addresses.

3. Tools are developed that automate the collection = of addresses and the sending out of messages.

4. At a certain time, there are enough people using = email out there that this whole area of email advertising is a huge financial marketplace. Companies/entities set up server farms to just send out = tons of email messages. (Defenders blacklist those servers.)

5. Those "servers" get distributed into = massive botnets and are then able to avoid blacklisting, etc.

 

I have absolutely no doubt that SIP spam will = unfortunately follow the exact same trajectory. We're already seeing the tools to = automate SPIT (here's one: http://www.hacki= ngvoip.com/tools/spitter.tar.gz ).  At some point we will hit my #4 when there are enough people = using SIP *with publicly accessible SIP addresses* that it becomes financially = lucrative enough for the larger automation to occur - and following on the heels = of that will be the botnets.  It will happen.  To me it's not a = question of IF but rather WHEN.

 

Right now, though, we're still in my steps 1-3 as = people start to get SIP endpoints and realize how they can abuse = them.

 

My concern about adding the focus on botnets into = RUCUS is the fact that we can easily get distracted into looking at how to solve = bigger issues and not get done the smaller issues that we can perhaps address = today.

 

Let's face it, probably all of us on this list = would be categorized as early adopters who like to explore cutting edge = technologies.  We like to chase bright shiny objects and what is new and sexy and interesting.  Let's say that you have a choice at the next IETF to = listen to either:

1. a presentation on a SIP header to pass a = "spam score" value between a SIP proxy and a UA; or

2. a presentation about SIP botnets, how they are constructed and the threats they pose.

I would expect that probably 90% of us would choose = the botnet talk. (No disrespect intended to the spam-score folks, just using = an example.) The reality, though, is that the spam score discussion might = be far more useful in moving us toward solutions that will help us with the people = abusing SIP systems today.  I don't want to wake up some day and find out = that while we've been having a ton of discussions about botnets, some idiot meanwhile is repeatedly connecting to my SIP server and pumping our = voicemail system full of SPIT.

 

Maybe it's crazy on my part, but I want to see = RUCUS have a charter that results in an achievable plan and = architecture.

 

Yes, we should consider botnets as a potential = source of SIP spam and, yes, the potential existence of SIP botnets should be included = in our thinking about an architecture to address SIP spam (so that any = architecture we come up with does not discount dealing with botnets).  But I also = think we need to stay focused on what we can do now about the threats that are = out there today (before it's too late).   Let's crawl first, then walk, = then run.

 

My 2 cents,

Dan

 

On Feb 19, 2008, at 11:51 AM, Juergen Quittek = wrote:

Today, most of the = spam email comes from bot-nets and recently

email spammers started to send massively from = compromized

valid email accounts.  I do not see why this would not become

also the biggest source of SIP spam in the = future.

 

Consequently, we should address this issue when = developing an

architecture for reducing SIP spam in the RUCUS = WG.  The

architecture should be general enough for covering = also means

that reduce SIP spam from bot nets and compromized = accounts

 

Whether or not to work on this problem is being = discussed

highly controversially in the IETF. But considering = that the

RUCUS BoF is targeted at establishing not a regular = working

group, but an RFC 5111 Exploratory Group, I do not = think it

would be appropriate to exclude such work from the beginning.

 

It should rather be part of the exploratory work to = find out

whether or not reducing SIP spam from bot nets is a = target

worth to be attacked by the IETF.

 

-- 

Dan York, CISSP, Director of Emerging Communication = Technology

Office of the CTO    Voxeo Corporation   =   dyork@voxeo.com

=

Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com<= /p>

 

Bring your web applications to the = phone.

Find out how at http://evolution.voxeo.com

 

 



 

  =

DISCLAIMER
The = information contained in this electronic mail may be confidential or = legally privileged. It is for the intended recipient(s) only. Should you = receive this message in error, please notify the sender by replying to = this mail. Unless expressly stated, opinions in this message are those = of the individual sender and not of GFI. Unauthorized use of the = contents is strictly prohibited. While all care has been taken, GFI is = not responsible for the integrity of the contents of this electronic = mail and any attachments included within.

This mail was checked for = viruses by GFI MailSecurity. GFI also develops anti-spam software (GFI = MailEssentials), a fax server (GFI FAXmaker), and network security and = management software (GFI LANguard) - www.gfi.com

------_=_NextPart_001_01C8739B.DA973F1D-- --===============1148480821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1148480821==-- From rucus-bounces@ietf.org Wed Feb 20 01:20:52 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766583A6913; Wed, 20 Feb 2008 01:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=-1.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKlMbsn8lW4u; Wed, 20 Feb 2008 01:20:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B4E28C181; Wed, 20 Feb 2008 01:20:51 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE41C3A6999 for ; Wed, 20 Feb 2008 01:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0qsPP0bXmpp for ; Wed, 20 Feb 2008 01:20:45 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id CA2A53A6913 for ; Wed, 20 Feb 2008 01:20:44 -0800 (PST) Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id m1K9KecZ014689; Wed, 20 Feb 2008 10:20:40 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id m1K9KdrX010925; Wed, 20 Feb 2008 10:20:40 +0100 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Feb 2008 10:20:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 10:20:38 +0100 Message-ID: <198A10EC585EC74687BCA414E2A5971802093A04@MCHP7RDA.ww002.siemens.net> In-Reply-To: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] Botnets, take 2... Re: [Rucus] Draft RUCUS charter Thread-Index: AchzNVa8Vbt2xm67QgS+RRpF0kzNNgAaZhsw References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> From: "Fischer, Kai" To: , "Juergen Quittek" X-OriginalArrivalTime: 20 Feb 2008 09:20:38.0759 (UTC) FILETIME=[DB618770:01C873A1] Cc: Signaling TO Prevent SPIT Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi, I think, in the past discussions two different issues (botnet and identity theft) are combined, but need to be discussed / addressed separately. Most people consider with the term 'botnet' a number of captured hosts, which will be used for attacks like DoS, SPAM or SPIT. They are using the IP address identity of the captured host but not usually the authenticated application identity. Here, mechanism like DKIM for email SPAM or other approaches can counter such threats. Identity theft is even more challenging to solve regardless if an attack is initiated by a single captured host or in worst case a botnet of captured host including identity thefts. Kai ________________________________ From: spitstop-bounces@listserv.netlab.nec.de [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of Dan York Sent: Dienstag, 19. Februar 2008 21:24 To: Juergen Quittek Cc: rucus@ietf.org; Signaling TO Prevent SPIT Subject: [spitstop] Botnets, take 2... Re: [Rucus] Draft RUCUS charter Juergen (and Saverio and others), I appreciate the point you are raising here. My interest and passion are in networking, communication and security. To me, botnets are both incredibly fascinating and incredibly terrifying. I agree with you that botnets very certainly may be the biggest source of SIP spam in the future. Here's my problem: We have to crawl before we can walk and before we can run. Let's say that this is the (incredibly simplistic view of the) evolution of email spam: 1. Someone figures out that they can send advertisements to a range of email addresses they have collected. 2. Someone realizes that they can add those addresses to a "mailing list" to easily send to a large number of addresses. 3. Tools are developed that automate the collection of addresses and the sending out of messages. 4. At a certain time, there are enough people using email out there that this whole area of email advertising is a huge financial marketplace. Companies/entities set up server farms to just send out tons of email messages. (Defenders blacklist those servers.) 5. Those "servers" get distributed into massive botnets and are then able to avoid blacklisting, etc. I have absolutely no doubt that SIP spam will unfortunately follow the exact same trajectory. We're already seeing the tools to automate SPIT (here's one: http://www.hackingvoip.com/tools/spitter.tar.gz ). At some point we will hit my #4 when there are enough people using SIP *with publicly accessible SIP addresses* that it becomes financially lucrative enough for the larger automation to occur - and following on the heels of that will be the botnets. It will happen. To me it's not a question of IF but rather WHEN. Right now, though, we're still in my steps 1-3 as people start to get SIP endpoints and realize how they can abuse them. My concern about adding the focus on botnets into RUCUS is the fact that we can easily get distracted into looking at how to solve bigger issues and not get done the smaller issues that we can perhaps address today. Let's face it, probably all of us on this list would be categorized as early adopters who like to explore cutting edge technologies. We like to chase bright shiny objects and what is new and sexy and interesting. Let's say that you have a choice at the next IETF to listen to either: 1. a presentation on a SIP header to pass a "spam score" value between a SIP proxy and a UA; or 2. a presentation about SIP botnets, how they are constructed and the threats they pose. I would expect that probably 90% of us would choose the botnet talk. (No disrespect intended to the spam-score folks, just using an example.) The reality, though, is that the spam score discussion might be far more useful in moving us toward solutions that will help us with the people abusing SIP systems today. I don't want to wake up some day and find out that while we've been having a ton of discussions about botnets, some idiot meanwhile is repeatedly connecting to my SIP server and pumping our voicemail system full of SPIT. Maybe it's crazy on my part, but I want to see RUCUS have a charter that results in an achievable plan and architecture. Yes, we should consider botnets as a potential source of SIP spam and, yes, the potential existence of SIP botnets should be included in our thinking about an architecture to address SIP spam (so that any architecture we come up with does not discount dealing with botnets). But I also think we need to stay focused on what we can do now about the threats that are out there today (before it's too late). Let's crawl first, then walk, then run. My 2 cents, Dan On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: Today, most of the spam email comes from bot-nets and recently email spammers started to send massively from compromized valid email accounts. I do not see why this would not become also the biggest source of SIP spam in the future. Consequently, we should address this issue when developing an architecture for reducing SIP spam in the RUCUS WG. The architecture should be general enough for covering also means that reduce SIP spam from bot nets and compromized accounts Whether or not to work on this problem is being discussed highly controversially in the IETF. But considering that the RUCUS BoF is targeted at establishing not a regular working group, but an RFC 5111 Exploratory Group, I do not think it would be appropriate to exclude such work from the beginning. It should rather be part of the exploratory work to find out whether or not reducing SIP spam from bot nets is a target worth to be attacked by the IETF. -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Feb 20 02:18:02 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3715928C105; Wed, 20 Feb 2008 02:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.324 X-Spam-Level: X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_27=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekRkDFCINEW1; Wed, 20 Feb 2008 02:18:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71DDB3A696B; Wed, 20 Feb 2008 02:18:01 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A993A6927 for ; Wed, 20 Feb 2008 02:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hAdqA3PLqNt for ; Wed, 20 Feb 2008 02:17:58 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 740A53A680E for ; Wed, 20 Feb 2008 02:17:58 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3F7902C000357; Wed, 20 Feb 2008 11:17:55 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrMmsAsSs-NU; Wed, 20 Feb 2008 11:17:55 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 280F22C000355; Wed, 20 Feb 2008 11:17:45 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 11:17:43 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D1178@mx1.office> In-Reply-To: <47BB26AB.8080708@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Draft RUCUS charter Thread-Index: AchzKXmstywrpqq3QoGuaPWkCt8MfgAf7Gaw References: <47BB26AB.8080708@gmx.net> From: "Martin Stiemerling" To: , "Juergen Quittek" Cc: rucus@ietf.org Subject: Re: [Rucus] Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > > I do,however, agree with you that we should explicitly > indicate that we want to explore different architectural > approaches. Even though white lists are quite common in > today's instant messaging world they are more or less unknown > in the PSTN. The user's behavior will be quite important to Ehm, yes and no. Whitelisting might be somewhat unknown for the PSTN network but not for PSTN end devices (i.e., phones). My phones at home, plus my mobile, can do whitelisting. However, the feature is not called whitelisting, but has different various names. The feature allows to define a set of phone numbers that are allowed to call my phone. If no phone number is provided during a call setup or the number is not listed, the call is not accepted or immediately rejected (configuration issue). This is also configurable on a time of day basis. > understand with some of these different approaches. > > I agree that looking at botnets and similar mechanisms is > useful. Still, I would avoid the term "open Internet" since > it is somewhat fuzzy. Aren't we in the IETF, i.e., have to deal with the Internet anyhow? > > Regarding your paragraph: > " > Strong identities and white lists will be essential in a well > protected environment but do not solve the problem in the > open Internet. In the open Internet compromised accounts and > bot-nets are the major source of email spam today and > expected to be the major source of SIP spam in the future. > " > > We might need to ask the DKIM folks to better understand the > current state of the art in email spam. For example: Are > compromised accounts really a major source of email spam today? Yes, they are. See Dan's and my emails to this. Read the heise.de news message. Regards, Martin stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Feb 20 02:39:52 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1983A6854; Wed, 20 Feb 2008 02:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg20AR-8NZnV; Wed, 20 Feb 2008 02:39:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5C228C0DE; Wed, 20 Feb 2008 02:39:44 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB18D28C19B for ; Wed, 20 Feb 2008 02:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzMJHeHp-k54 for ; Wed, 20 Feb 2008 02:39:35 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id ADEEB28C0DE for ; Wed, 20 Feb 2008 02:39:34 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28081616 for rucus@ietf.org; Wed, 20 Feb 2008 10:39:29 +0000 Mime-Version: 1.0 (Apple Message framework v753) To: rucus BoF Message-Id: <3DB16754-25C0-48B1-8A47-8E95E51AD357@voxeo.com> From: Dan York Date: Wed, 20 Feb 2008 05:39:27 -0500 X-Mailer: Apple Mail (2.753) Subject: [Rucus] RUCUS list web archive is now updating... new members can see the discussion... X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1810308079==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1810308079== Content-Type: multipart/alternative; boundary=Apple-Mail-157--289015494 --Apple-Mail-157--289015494 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI, the RUCUS mailing list web archive *is* now updating correctly (turned out to be a permissions problem) and is visible at: http://www.ietf.org/mail-archive/web/rucus/current/maillist.html If you just joined the list you may want to take a look through the archive as we've been having a fair bit of discussion over the past few days. Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-157--289015494 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI, the RUCUS mailing list web archive *is* now updating correctly = (turned out to be a permissions problem) and is visible at:

=

If you just = joined the list you may want to take a look through the archive as we've = been having a fair bit of discussion over the past few = days.

Regards,
Dan
--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-157--289015494-- --===============1810308079== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1810308079==-- From rucus-bounces@ietf.org Wed Feb 20 05:21:42 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761D528C7F7; Wed, 20 Feb 2008 05:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=-2.279, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gfPSTKQxAnH; Wed, 20 Feb 2008 05:21:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480C928C263; Wed, 20 Feb 2008 05:21:41 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33FD13A69AF for ; Wed, 20 Feb 2008 05:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2F8doh4pxZO for ; Wed, 20 Feb 2008 05:21:38 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 7FE8628C263 for ; Wed, 20 Feb 2008 05:21:38 -0800 (PST) Received: from [192.168.0.57] (pool-71-250-74-26.nwrknj.east.verizon.net [71.250.74.26]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m1KDLWm0021637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2008 08:21:33 -0500 (EST) Message-Id: <909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu> From: Henning Schulzrinne To: Brian Azzopardi In-Reply-To: <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 08:21:44 -0500 References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: rucus@ietf.org, Signaling TO Prevent SPIT , Juergen Quittek Subject: Re: [Rucus] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org There are three sub-cases of bot nets: - Just uses host, without credentials: identity-based whitelisting = works (subject to the usual problems with whitelisting) - Uses credentials, but spews randomly: unlikely that the recipient = will have that person in their whitelist, so still manageable. - Uses credentials, spams addresses in addressbook: whitelists don't = help, but at least the sender can be identified and fixed/fined/taken = offline. I'm not trying to downplay bot nets, just that this is a bit more = nuanced. Henning On Feb 20, 2008, at 3:37 AM, Brian Azzopardi wrote: > Dan, > > I am afraid that we may have to hit the ground running. Email spam = > is already a big industry with well established operators. Spewing = > out SPIT instead of email spam is just another =91product=92 for them. = > Only amateur SPITers will use spitter and other such tools =96 the = > professional ones already have the infrastructure in place and = > they=92d be irrational not to reuse it for SPIT =96 they will just short- = > circuit to your step 5. We do need to think deeply about botnets =96 = > they are the principal means of sending spam and have been for at = > least the last 2 years. > > Regards, > > Brian Azzopardi - Senior Business Analyst > GFI Software - www.gfi.com > > > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On = > Behalf Of Dan York > Sent: 19 February 2008 21:24 > To: Juergen Quittek > Cc: rucus@ietf.org; Signaling TO Prevent SPIT > Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter > > Juergen (and Saverio and others), > > I appreciate the point you are raising here. My interest and = > passion are in networking, communication and security. To me, = > botnets are both incredibly fascinating and incredibly terrifying. = > I agree with you that botnets very certainly may be the biggest = > source of SIP spam in the future. > > Here's my problem: > > We have to crawl before we can walk and before we can run. > > Let's say that this is the (incredibly simplistic view of the) = > evolution of email spam: > > 1. Someone figures out that they can send advertisements to a range = > of email addresses they have collected. > 2. Someone realizes that they can add those addresses to a "mailing = > list" to easily send to a large number of addresses. > 3. Tools are developed that automate the collection of addresses and = > the sending out of messages. > 4. At a certain time, there are enough people using email out there = > that this whole area of email advertising is a huge financial = > marketplace. Companies/entities set up server farms to just send out = > tons of email messages. (Defenders blacklist those servers.) > 5. Those "servers" get distributed into massive botnets and are then = > able to avoid blacklisting, etc. > > I have absolutely no doubt that SIP spam will unfortunately follow = > the exact same trajectory. We're already seeing the tools to = > automate SPIT (here's one: http://www.hackingvoip.com/tools/spitter.tar.g= z = > ). At some point we will hit my #4 when there are enough people = > using SIP *with publicly accessible SIP addresses* that it becomes = > financially lucrative enough for the larger automation to occur - = > and following on the heels of that will be the botnets. It will = > happen. To me it's not a question of IF but rather WHEN. > > Right now, though, we're still in my steps 1-3 as people start to = > get SIP endpoints and realize how they can abuse them. > > My concern about adding the focus on botnets into RUCUS is the fact = > that we can easily get distracted into looking at how to solve = > bigger issues and not get done the smaller issues that we can = > perhaps address today. > > Let's face it, probably all of us on this list would be categorized = > as early adopters who like to explore cutting edge technologies. We = > like to chase bright shiny objects and what is new and sexy and = > interesting. Let's say that you have a choice at the next IETF to = > listen to either: > 1. a presentation on a SIP header to pass a "spam score" value = > between a SIP proxy and a UA; or > 2. a presentation about SIP botnets, how they are constructed and = > the threats they pose. > I would expect that probably 90% of us would choose the botnet talk. = > (No disrespect intended to the spam-score folks, just using an = > example.) The reality, though, is that the spam score discussion = > might be far more useful in moving us toward solutions that will = > help us with the people abusing SIP systems today. I don't want to = > wake up some day and find out that while we've been having a ton of = > discussions about botnets, some idiot meanwhile is repeatedly = > connecting to my SIP server and pumping our voicemail system full of = > SPIT. > > Maybe it's crazy on my part, but I want to see RUCUS have a charter = > that results in an achievable plan and architecture. > > Yes, we should consider botnets as a potential source of SIP spam = > and, yes, the potential existence of SIP botnets should be included = > in our thinking about an architecture to address SIP spam (so that = > any architecture we come up with does not discount dealing with = > botnets). But I also think we need to stay focused on what we can = > do now about the threats that are out there today (before it's too = > late). Let's crawl first, then walk, then run. > > My 2 cents, > Dan > > On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: > Today, most of the spam email comes from bot-nets and recently > email spammers started to send massively from compromized > valid email accounts. I do not see why this would not become > also the biggest source of SIP spam in the future. > > Consequently, we should address this issue when developing an > architecture for reducing SIP spam in the RUCUS WG. The > architecture should be general enough for covering also means > that reduce SIP spam from bot nets and compromized accounts > > Whether or not to work on this problem is being discussed > highly controversially in the IETF. But considering that the > RUCUS BoF is targeted at establishing not a regular working > group, but an RFC 5111 Exploratory Group, I do not think it > would be appropriate to exclude such work from the beginning. > > It should rather be part of the exploratory work to find out > whether or not reducing SIP spam from bot nets is a target > worth to be attacked by the IETF. > > -- = > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > > > > DISCLAIMER > The information contained in this electronic mail may be = > confidential or legally privileged. It is for the intended = > recipient(s) only. Should you receive this message in error, please = > notify the sender by replying to this mail. Unless expressly stated, = > opinions in this message are those of the individual sender and not = > of GFI. Unauthorized use of the contents is strictly prohibited. = > While all care has been taken, GFI is not responsible for the = > integrity of the contents of this electronic mail and any = > attachments included within. > > This mail was checked for viruses by GFI MailSecurity. GFI also = > develops anti-spam software (GFI MailEssentials), a fax server (GFI = > FAXmaker), and network security and management software (GFI = > LANguard) - www.gfi.com > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Feb 20 06:29:00 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F4C28C75E; Wed, 20 Feb 2008 06:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.117 X-Spam-Level: X-Spam-Status: No, score=0.117 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5i-P8CeBIDSB; Wed, 20 Feb 2008 06:28:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054C028C189; Wed, 20 Feb 2008 06:28:58 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6513A68A3 for ; Wed, 20 Feb 2008 06:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtqMhCSnZHu7 for ; Wed, 20 Feb 2008 06:28:54 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 979393A69AF for ; Wed, 20 Feb 2008 06:28:53 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28083936; Wed, 20 Feb 2008 14:28:48 +0000 In-Reply-To: <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <00ED52BA-F846-4809-8D71-238C7858A2D2@voxeo.com> From: Dan York Date: Wed, 20 Feb 2008 09:28:46 -0500 To: Brian Azzopardi X-Mailer: Apple Mail (2.753) Cc: rucus@ietf.org, Signaling TO Prevent SPIT , Juergen Quittek Subject: Re: [Rucus] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1216542269==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1216542269== Content-Type: multipart/alternative; boundary=Apple-Mail-162--275256759 --Apple-Mail-162--275256759 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Brian, Again, I absolutely agree that botnets will potentially be the =20 largest source of SIP spam in the future when the financial =20 conditions are right for the botnet operators to branch out into SIP =20 spam. My point is this - today, in February 2008, why in the world would =20 any botnet operator waste their time on doing so? Where is the market? Asked another way, how many of us *on this list* can accept SIP =20 connections from **any random SIP endpoint** on the Internet? That is the necessary condition for there to be a market for a botnet =20= operator to spend the time to move into SIP spam. Otherwise, why =20 bother? Email spam is undoubtedly far more financially lucrative. Let's look at this another way: 1. How many of us are candidates for email spam? (i.e. our email =20 address can accept email from any random email sender) - Answer: 100% (subject to whatever anti-email-spam measures =20 we've already got in place, but we are *candidates* anyway) 2. How many of us are candidates for PSTN voice spam? (a.k.a. =20 telemarketers) - Answer: 100% (we all have phones and can receive calls from =20 anyone else out there on the PSTN) 3. How many of us are candidates for SIP voice spam? (i.e. our SIP =20 UA can accept SIP connections from any other random SIP endpoint) - Answer: ??? 1%? 2%? 5%? 10%? In casual conversations with other people *within IETF* I have found =20 that most folks I have spoken with cannot receive incoming SIP calls =20 from any random SIP endpoint. In some cases it is blocked by =20 firewalls. In some cases their PBX, IP-PBX or home system simply =20 isn't using SIP. How many of us here on this RUCUS list can accept inbound SIP calls =20 from any random SIP endpoint? (I can, but anecdotally I seem to be in a minority.) When the number of SIP endpoints that can be reached by any other =20 random SIP endpoint is sufficiently large to be of interest, *that* =20 is when I believe the botnet operators and other entities doing =20 automated spam will pay attention to SIP spam. Before that point, =20 there is simply no ROI. And if we don't have sufficient mechanisms in place by that time to =20 deal with botnet-spewed SIP spam, we and our industry will suffer. When is that "point"? 2008? 2009? 2010? 2020? I don't know. I =20 would expect it's probably not this year or next, but beyond that my =20 crystal ball gets really murky. So yes, we need to consider the potential future impact of botnets in =20= our discussions and in our architecture decisions, etc. But what I don't want to personally see is that this mailing list and/=20= or the RUCUS session in Philadelphia becomes so focused on SIP =20 botnets that we don't deal with the more current issues that we can =20 address today. Dan On Feb 20, 2008, at 3:37 AM, Brian Azzopardi wrote: > Dan, > > I am afraid that we may have to hit the ground running. Email spam =20 > is already a big industry with well established operators. Spewing =20 > out SPIT instead of email spam is just another =91product=92 for them. = =20 > Only amateur SPITers will use spitter and other such tools =96 the =20 > professional ones already have the infrastructure in place and =20 > they=92d be irrational not to reuse it for SPIT =96 they will just =20 > short-circuit to your step 5. We do need to think deeply about =20 > botnets =96 they are the principal means of sending spam and have =20 > been for at least the last 2 years. > > Regards, > > Brian Azzopardi - Senior Business Analyst > GFI Software - www.gfi.com > > > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On =20 > Behalf Of Dan York > Sent: 19 February 2008 21:24 > To: Juergen Quittek > Cc: rucus@ietf.org; Signaling TO Prevent SPIT > Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter > > Juergen (and Saverio and others), > > I appreciate the point you are raising here. My interest and =20 > passion are in networking, communication and security. To me, =20 > botnets are both incredibly fascinating and incredibly terrifying. =20= > I agree with you that botnets very certainly may be the biggest =20 > source of SIP spam in the future. > > Here's my problem: > > We have to crawl before we can walk and before we can run. > > Let's say that this is the (incredibly simplistic view of the) =20 > evolution of email spam: > > 1. Someone figures out that they can send advertisements to a range =20= > of email addresses they have collected. > 2. Someone realizes that they can add those addresses to a "mailing =20= > list" to easily send to a large number of addresses. > 3. Tools are developed that automate the collection of addresses =20 > and the sending out of messages. > 4. At a certain time, there are enough people using email out there =20= > that this whole area of email advertising is a huge financial =20 > marketplace. Companies/entities set up server farms to just send =20 > out tons of email messages. (Defenders blacklist those servers.) > 5. Those "servers" get distributed into massive botnets and are =20 > then able to avoid blacklisting, etc. > > I have absolutely no doubt that SIP spam will unfortunately follow =20 > the exact same trajectory. We're already seeing the tools to =20 > automate SPIT (here's one: http://www.hackingvoip.com/tools/=20 > spitter.tar.gz ). At some point we will hit my #4 when there are =20 > enough people using SIP *with publicly accessible SIP addresses* =20 > that it becomes financially lucrative enough for the larger =20 > automation to occur - and following on the heels of that will be =20 > the botnets. It will happen. To me it's not a question of IF but =20 > rather WHEN. > > Right now, though, we're still in my steps 1-3 as people start to =20 > get SIP endpoints and realize how they can abuse them. > > My concern about adding the focus on botnets into RUCUS is the fact =20= > that we can easily get distracted into looking at how to solve =20 > bigger issues and not get done the smaller issues that we can =20 > perhaps address today. > > Let's face it, probably all of us on this list would be categorized =20= > as early adopters who like to explore cutting edge technologies. =20 > We like to chase bright shiny objects and what is new and sexy and =20 > interesting. Let's say that you have a choice at the next IETF to =20 > listen to either: > 1. a presentation on a SIP header to pass a "spam score" value =20 > between a SIP proxy and a UA; or > 2. a presentation about SIP botnets, how they are constructed and =20 > the threats they pose. > I would expect that probably 90% of us would choose the botnet =20 > talk. (No disrespect intended to the spam-score folks, just using =20 > an example.) The reality, though, is that the spam score discussion =20= > might be far more useful in moving us toward solutions that will =20 > help us with the people abusing SIP systems today. I don't want to =20= > wake up some day and find out that while we've been having a ton of =20= > discussions about botnets, some idiot meanwhile is repeatedly =20 > connecting to my SIP server and pumping our voicemail system full =20 > of SPIT. > > Maybe it's crazy on my part, but I want to see RUCUS have a charter =20= > that results in an achievable plan and architecture. > > Yes, we should consider botnets as a potential source of SIP spam =20 > and, yes, the potential existence of SIP botnets should be included =20= > in our thinking about an architecture to address SIP spam (so that =20 > any architecture we come up with does not discount dealing with =20 > botnets). But I also think we need to stay focused on what we can =20 > do now about the threats that are out there today (before it's too =20 > late). Let's crawl first, then walk, then run. > > My 2 cents, > Dan > > On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: > Today, most of the spam email comes from bot-nets and recently > email spammers started to send massively from compromized > valid email accounts. I do not see why this would not become > also the biggest source of SIP spam in the future. > > Consequently, we should address this issue when developing an > architecture for reducing SIP spam in the RUCUS WG. The > architecture should be general enough for covering also means > that reduce SIP spam from bot nets and compromized accounts > > Whether or not to work on this problem is being discussed > highly controversially in the IETF. But considering that the > RUCUS BoF is targeted at establishing not a regular working > group, but an RFC 5111 Exploratory Group, I do not think it > would be appropriate to exclude such work from the beginning. > > It should rather be part of the exploratory work to find out > whether or not reducing SIP spam from bot nets is a target > worth to be attacked by the IETF. > > --=20 > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > > > > DISCLAIMER > The information contained in this electronic mail may be =20 > confidential or legally privileged. It is for the intended recipient=20= > (s) only. Should you receive this message in error, please notify =20 > the sender by replying to this mail. Unless expressly stated, =20 > opinions in this message are those of the individual sender and not =20= > of GFI. Unauthorized use of the contents is strictly prohibited. =20 > While all care has been taken, GFI is not responsible for the =20 > integrity of the contents of this electronic mail and any =20 > attachments included within. > > This mail was checked for viruses by GFI MailSecurity. GFI also =20 > develops anti-spam software (GFI MailEssentials), a fax server (GFI =20= > FAXmaker), and network security and management software (GFI =20 > LANguard) - www.gfi.com > --=20 Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-162--275256759 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Brian,

Again, I = absolutely agree that botnets will potentially be the largest source of = SIP spam in the future when the financial conditions are right for the = botnet operators to branch out into SIP spam.

My point is this - today, = in February 2008, why in the world would any botnet operator waste their = time on doing so? =A0Where is the market?

Asked another way, how = many of us *on this list* can accept SIP connections from **any random = SIP endpoint** on the Internet? =A0=A0

That is the necessary = condition for there to be a market for a botnet operator to spend the = time to move into SIP spam. Otherwise, why bother? Email spam is = undoubtedly far more financially lucrative.

Let's look at this another = way:

1. How = many of us are candidates for email spam? (i.e. our email address can = accept email from any random email sender)
=A0=A0 =A0 - = Answer: 100% =A0(subject to whatever anti-email-spam measures we've = already got in place, but we are *candidates* anyway)

2. How many of us are = candidates for PSTN voice spam? (a.k.a. telemarketers)
=A0=A0 = =A0 - Answer: 100% =A0(we all have phones and can receive calls from = anyone else out there on the PSTN)

3. How many of us are = candidates for SIP voice spam? =A0(i.e. our SIP UA can accept SIP = connections from any other random SIP endpoint)
=A0=A0 =A0 - = Answer: =A0??? =A0 1%? =A02%? =A05%? =A010%?

In casual conversations = with other people *within IETF* I have found that most folks I have = spoken with cannot receive incoming SIP calls from any random SIP = endpoint. =A0In some cases it is blocked by firewalls. In some cases = their PBX, IP-PBX or home system simply isn't using SIP.=A0

How many of us here on = this RUCUS list can accept inbound SIP calls from any random SIP = endpoint? =A0=A0
(I can, but anecdotally I seem to be in a = minority.)

When the number of SIP = endpoints that can be reached by any other random SIP endpoint is = sufficiently large to be of interest, *that* is when I believe the = botnet operators and other entities doing automated spam will pay = attention to SIP spam. =A0Before that point, there is simply no = ROI.

And if = we don't have sufficient mechanisms in place by that time to deal with = botnet-spewed SIP spam, we and our industry will suffer.

When is that "point"? = =A02008? 2009? =A02010? 2020? =A0I don't know. I would expect it's = probably not this year or next, but beyond that my crystal ball gets = really murky.

So yes, we need to = consider the potential future impact of botnets in our discussions and = in our architecture decisions, etc.

But what I don't want to = personally see is that this mailing list and/or the RUCUS session in = Philadelphia becomes so focused on SIP botnets that we don't deal with = the more current issues that we can address today.

Dan

On Feb 20, 2008, = at 3:37 AM, Brian Azzopardi wrote:

Dan,
=A0
I am afraid that we may have to = hit the ground running. Email spam is already a big industry with well = established operators. Spewing out SPIT instead of email spam is just = another =91product=92 for them. Only amateur SPITers will use spitter = and other such tools =96 the professional ones already have the = infrastructure in place and they=92d be irrational not to reuse it for = SPIT =96 they will just short-circuit to your step 5. =A0We do need to = think deeply about botnets =96 they are the principal means of sending = spam and have been for at least the last 2 = years.
Brian = Azzopardi - Senior Business Analyst
GFI Software -=A0=A0
From:=A0rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org]<= span class=3D"Apple-converted-space">=A0On Behalf Of=A0Dan = York
Sent:=A019 = February 2008 21:24
To:=A0Juergen = Quittek
Cc:=A0rucus@ietf.org; Signaling TO Prevent = SPIT
Subject:=A0[Rucus] Botnets, take 2... Re: = Draft RUCUS charter
=A0
Juergen (and Saverio and = others),
I appreciate the point = you are raising here. =A0My interest and passion are in networking, = communication and security. =A0To me, botnets are both incredibly = fascinating and incredibly terrifying. =A0I agree with you that botnets = very certainly may be the biggest source of SIP spam in the = future.
Here's my = problem:
=A0=A0 =A0 We have to = crawl before we can walk and before we can = run.
Let's say that this is = the (incredibly simplistic view of the) evolution of email = spam:
1. Someone figures out = that they can send advertisements to a range of email addresses they = have collected.
2. Someone = realizes that they can add those addresses to a "mailing list" to easily = send to a large number of addresses.
3. Tools are developed that automate the collection of = addresses and the sending out of = messages.
4. At a certain time, = there are enough people using email out there that this whole area of = email advertising is a huge financial marketplace. Companies/entities = set up server farms to just send out tons of email messages. (Defenders = blacklist those servers.)
5. Those "servers" get distributed into massive botnets = and are then able to avoid blacklisting, = etc.
=A0

DISCLAIMER
The information = contained in this electronic mail may be confidential or legally = privileged. It is for the intended recipient(s) only. Should you receive = this message in error, please notify the sender by replying to this = mail. Unless expressly stated, opinions in this message are those of the = individual sender and not of GFI. Unauthorized use of the contents is = strictly prohibited. While all care has been taken, GFI is not = responsible for the integrity of the contents of this electronic mail = and any attachments included within.

This mail was checked for viruses by GFI = MailSecurity. GFI also develops anti-spam software (GFI MailEssentials), = a fax server (GFI FAXmaker), and network security and management = software (GFI LANguard) -=A0<= a href=3D"http://www.gfi.com" style=3D"color: blue; text-decoration: = underline; = ">www.gfi.com


--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=
= --Apple-Mail-162--275256759-- --===============1216542269== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1216542269==-- From rucus-bounces@ietf.org Wed Feb 20 06:35:19 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED793A6E38; Wed, 20 Feb 2008 06:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ibk21yRramvi; Wed, 20 Feb 2008 06:35:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B313A6CA8; Wed, 20 Feb 2008 06:35:18 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE533A6CA8 for ; Wed, 20 Feb 2008 06:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+O4IKLSUDT4 for ; Wed, 20 Feb 2008 06:35:16 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 26F923A6A3E for ; Wed, 20 Feb 2008 06:35:16 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D4D1F2C002B4A for ; Wed, 20 Feb 2008 15:35:12 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nt-CjbQUt-AX for ; Wed, 20 Feb 2008 15:35:12 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id B906A2C000355 for ; Wed, 20 Feb 2008 15:35:07 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 15:35:06 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D11DA@mx1.office> In-Reply-To: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] Botnets, take 2... Re: [Rucus] Draft RUCUS charter Thread-Index: AchzNWaz76bl9Nk1QhK2t8KfpOFi5wAl28lw References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> From: "Saverio Niccolini" To: Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi, just a small comment, RFC 5111 says: "the goal of an Exploratory Group is to put in place the prerequisites for formation of a Working Group" Thus I do not think we should start excluding any direction from the beginning, we are here to explore. RUCUS is not going to be a normal WG but an exploratory one. We should think of an architecture that is able to accomodate many potential building blocks. If, after the approval of RUCUS and during its lifetime, we realize that some building blocks do not fit the big picture then we can drop them. But not exclude them a priori. Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: spitstop-bounces@listserv.netlab.nec.de > [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of Dan York > Sent: Tuesday, February 19, 2008 9:24 PM > To: Juergen Quittek > Cc: rucus@ietf.org; Signaling TO Prevent SPIT > Subject: [spitstop] Botnets, take 2... Re: [Rucus] Draft RUCUS charter > > Juergen (and Saverio and others), > > I appreciate the point you are raising here. My interest and > passion are in networking, communication and security. To > me, botnets are both incredibly fascinating and incredibly > terrifying. I agree with you that botnets very certainly may > be the biggest source of SIP spam in the future. > > Here's my problem: > > We have to crawl before we can walk and before we can run. > > Let's say that this is the (incredibly simplistic view of > the) evolution of email spam: > > 1. Someone figures out that they can send advertisements to a > range of email addresses they have collected. > 2. Someone realizes that they can add those addresses to a > "mailing list" to easily send to a large number of addresses. > 3. Tools are developed that automate the collection of > addresses and the sending out of messages. > 4. At a certain time, there are enough people using email out > there that this whole area of email advertising is a huge > financial marketplace. Companies/entities set up server farms > to just send out tons of email messages. (Defenders blacklist > those servers.) 5. Those "servers" get distributed into > massive botnets and are then able to avoid blacklisting, etc. > > I have absolutely no doubt that SIP spam will unfortunately > follow the exact same trajectory. We're already seeing the > tools to automate SPIT (here's one: > http://www.hackingvoip.com/tools/spitter.tar.gz ). At some > point we will hit my #4 when there are enough people using > SIP *with publicly accessible SIP addresses* that it becomes > financially lucrative enough for the larger automation to > occur - and following on the heels of that will be the > botnets. It will happen. To me it's not a question of IF > but rather WHEN. > > Right now, though, we're still in my steps 1-3 as people > start to get SIP endpoints and realize how they can abuse them. > > My concern about adding the focus on botnets into RUCUS is > the fact that we can easily get distracted into looking at > how to solve bigger issues and not get done the smaller > issues that we can perhaps address today. > > Let's face it, probably all of us on this list would be > categorized as early adopters who like to explore cutting > edge technologies. We like to chase bright shiny objects and > what is new and sexy and interesting. Let's say that you > have a choice at the next IETF to listen to either: > 1. a presentation on a SIP header to pass a "spam score" > value between a SIP proxy and a UA; or 2. a presentation > about SIP botnets, how they are constructed and the threats they pose. > I would expect that probably 90% of us would choose the > botnet talk. (No disrespect intended to the spam-score folks, > just using an example.) The reality, though, is that the spam > score discussion might be far more useful in moving us toward > solutions that will help us with the people abusing SIP > systems today. I don't want to wake up some day and find out > that while we've been having a ton of discussions about > botnets, some idiot meanwhile is repeatedly connecting to my > SIP server and pumping our voicemail system full of SPIT. > > Maybe it's crazy on my part, but I want to see RUCUS have a > charter that results in an achievable plan and architecture. > > Yes, we should consider botnets as a potential source of SIP > spam and, yes, the potential existence of SIP botnets should > be included in our thinking about an architecture to address > SIP spam (so that any architecture we come up with does not > discount dealing with botnets). But I also think we need to > stay focused on what we can do now about the threats that are > out there today (before it's too late). Let's crawl first, > then walk, then run. > > My 2 cents, > Dan > > On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: > > Today, most of the spam email comes from bot-nets and recently > email spammers started to send massively from compromized > valid email accounts. I do not see why this would not become > also the biggest source of SIP spam in the future. > > Consequently, we should address this issue when developing an > architecture for reducing SIP spam in the RUCUS WG. The > architecture should be general enough for covering also means > that reduce SIP spam from bot nets and compromized accounts > > Whether or not to work on this problem is being discussed > highly controversially in the IETF. But considering that the > RUCUS BoF is targeted at establishing not a regular working > group, but an RFC 5111 Exploratory Group, I do not think it > would be appropriate to exclude such work from the beginning. > > It should rather be part of the exploratory work to find out > whether or not reducing SIP spam from bot nets is a target > worth to be attacked by the IETF. > > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Feb 20 06:40:49 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3E83A6E51; Wed, 20 Feb 2008 06:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK2btFNign1c; Wed, 20 Feb 2008 06:40:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9CF3A6E42; Wed, 20 Feb 2008 06:40:48 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9063A6E3A for ; Wed, 20 Feb 2008 06:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1th6psrIcW6 for ; Wed, 20 Feb 2008 06:40:45 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id DB1413A6965 for ; Wed, 20 Feb 2008 06:40:40 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6E8DB2C002B4A; Wed, 20 Feb 2008 15:40:37 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbKgYR0GVUt4; Wed, 20 Feb 2008 15:40:37 +0100 (CET) Received: by smtp0.neclab.eu (Postfix, from userid 1001) id 5C2FD2C009E8E; Wed, 20 Feb 2008 15:40:37 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 1D6C82C002B4A; Wed, 20 Feb 2008 15:40:27 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 15:40:26 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF4D11DB@mx1.office> In-Reply-To: <00ED52BA-F846-4809-8D71-238C7858A2D2@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] [Rucus] Botnets, take 2... Re: Draft RUCUS charter Thread-Index: AchzzP2rDZetWUoaTg+Y4KE/Jz9oNQAAQqKg References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com><42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> <00ED52BA-F846-4809-8D71-238C7858A2D2@voxeo.com> From: "Saverio Niccolini" To: X-Sanitizer: This message has been sanitized! Cc: Signaling TO Prevent SPIT Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dan, > Again, I absolutely agree that botnets will potentially be > the largest source of SIP spam in the future when the > financial conditions are right for the botnet operators to > branch out into SIP spam. > So yes, we need to consider the potential future impact of > botnets in our discussions and in our architecture decisions, etc. Then we have "Consensus"! It seems we all agree then, let's just be sure that this is reflected in the charter proposal and we are all happy and we will be able to have RUCUS as an exploratory WG. > But what I don't want to personally see is that this mailing > list and/or the RUCUS session in Philadelphia becomes so > focused on SIP botnets that we don't deal with the more > current issues that we can address today. Nobody is saying that, people only want to do not exclude some building blocks from the beginning and work on the big picture exactly as you want. Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Feb 20 07:04:09 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3E028C1CD; Wed, 20 Feb 2008 07:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ2iqzvNg8ur; Wed, 20 Feb 2008 07:04:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173813A6965; Wed, 20 Feb 2008 07:04:09 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8DE3A6965 for ; Wed, 20 Feb 2008 07:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKzwzIJ5+1YE for ; Wed, 20 Feb 2008 07:04:07 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 833783A68A3 for ; Wed, 20 Feb 2008 07:04:07 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 98FBF4C55E; Wed, 20 Feb 2008 16:04:02 +0100 (CET) Date: Wed, 20 Feb 2008 16:04:02 +0100 From: Otmar Lendl To: Dan York Message-ID: <20080220150402.GB27334@bofh.priv.at> References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> <00ED52BA-F846-4809-8D71-238C7858A2D2@voxeo.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <00ED52BA-F846-4809-8D71-238C7858A2D2@voxeo.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: rucus@ietf.org, Signaling TO Prevent SPIT , Juergen Quittek Subject: Re: [Rucus] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/20 15:02, Dan York wrote: [.. good points ..] > In casual conversations with other people *within IETF* I have found > that most folks I have spoken with cannot receive incoming SIP calls > from any random SIP endpoint. In some cases it is blocked by > firewalls. In some cases their PBX, IP-PBX or home system simply > isn't using SIP. > > How many of us here on this RUCUS list can accept inbound SIP calls > from any random SIP endpoint? > (I can, but anecdotally I seem to be in a minority.) I am. (well, if you're selling user-ENUM, you kind of have to be.) > When the number of SIP endpoints that can be reached by any other > random SIP endpoint is sufficiently large to be of interest, *that* > is when I believe the botnet operators and other entities doing > automated spam will pay attention to SIP spam. Before that point, > there is simply no ROI. > > And if we don't have sufficient mechanisms in place by that time to > deal with botnet-spewed SIP spam, we and our industry will suffer. > > When is that "point"? 2008? 2009? 2010? 2020? I don't know. I > would expect it's probably not this year or next, but beyond that my > crystal ball gets really murky. My freshly polished crystal ball tells me that this point simply will not be reached until a solution to the SPIT threat has been found and deployed. (100% effectiveness is not needed, it just needs to be in the same ballpark to what people tolerate in the PSTN world. The email experience isn't tolerable.) It's also conceivable that some intermediate equilibrium will establish itself which is neither as closed/firewalled as today, nor as completely open as the email world. /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Feb 20 09:39:05 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9310828C75B; Wed, 20 Feb 2008 09:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.144 X-Spam-Level: X-Spam-Status: No, score=0.144 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, HTML_OBFUSCATE_05_10=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwQ6W+HYIh7s; Wed, 20 Feb 2008 09:39:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9918F28C1DF; Wed, 20 Feb 2008 09:39:03 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3F028C1FF for ; Wed, 20 Feb 2008 09:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF4wtvfWAKdH for ; Wed, 20 Feb 2008 09:39:00 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id ACEF128C1DF for ; Wed, 20 Feb 2008 09:38:59 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28087285; Wed, 20 Feb 2008 17:38:54 +0000 In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF4D11DA@mx1.office> References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <5F6519BF2DE0404D99B7C75607FF76FF4D11DA@mx1.office> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <55DE3E54-6421-4632-AABE-D171D5D6E346@voxeo.com> From: Dan York Date: Wed, 20 Feb 2008 12:38:52 -0500 To: Saverio Niccolini X-Mailer: Apple Mail (2.753) Cc: rucus@ietf.org Subject: [Rucus] EG vs WG - Re: [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0892122257==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============0892122257== Content-Type: multipart/alternative; boundary=Apple-Mail-176--263850768 --Apple-Mail-176--263850768 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Saverio, Point taken. Count me as one who will look forward to the primer at the beginning of the RUCUS session about Exploratory Groups and their differentiation from Working Groups. I guess my concern is that we've been doing a whole lot of "exploration" of the whole area of SIP spam/SPIT for several years, as can been seen by the numerous drafts that have been written by a host of folks on this list (including yourself) as well as RFC 5039. Admittedly, and perhaps this is the key point, the exploration has been done in an *unstructured* way as people investigated topics related to SPIT that were of interest to them. The role of the RUCUS "EG" may be to provide the *structure* for that continued exploration. I do, though, believe that we do need to move as best we can toward identifying the key actions we can start to take and the guidance we can start to give people for how to potentially address the issue. Hence my interest in an achievable plan and architecture. I don't know when that magic point will be when we start seeing large volumes of SIP spam, but given as RFC 5039 points out: "Don't Wait Until It's Too Late". (And we know that any proposals we develop *do* take time to be first standardized and then actually deployed.) Thanks for the feedback, Dan On Feb 20, 2008, at 9:35 AM, Saverio Niccolini wrote: > Hi, > > just a small comment, RFC 5111 says: > "the goal of an Exploratory Group is to put in place the > prerequisites for formation of a Working Group" > > Thus I do not think we should start excluding any direction > from the beginning, we are here to explore. RUCUS is not going > to be a normal WG but an exploratory one. > > We should think of an architecture that is able to accomodate > many potential building blocks. > > If, after the approval of RUCUS and during its lifetime, we realize > that some building blocks do not fit the big picture then we can drop > them. But not exclude them a priori. > > Saverio > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > > >> -----Original Message----- >> From: spitstop-bounces@listserv.netlab.nec.de >> [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of Dan >> York >> Sent: Tuesday, February 19, 2008 9:24 PM >> To: Juergen Quittek >> Cc: rucus@ietf.org; Signaling TO Prevent SPIT >> Subject: [spitstop] Botnets, take 2... Re: [Rucus] Draft RUCUS >> charter >> >> Juergen (and Saverio and others), >> >> I appreciate the point you are raising here. My interest and >> passion are in networking, communication and security. To >> me, botnets are both incredibly fascinating and incredibly >> terrifying. I agree with you that botnets very certainly may >> be the biggest source of SIP spam in the future. >> >> Here's my problem: >> >> We have to crawl before we can walk and before we can run. >> >> Let's say that this is the (incredibly simplistic view of >> the) evolution of email spam: >> >> 1. Someone figures out that they can send advertisements to a >> range of email addresses they have collected. >> 2. Someone realizes that they can add those addresses to a >> "mailing list" to easily send to a large number of addresses. >> 3. Tools are developed that automate the collection of >> addresses and the sending out of messages. >> 4. At a certain time, there are enough people using email out >> there that this whole area of email advertising is a huge >> financial marketplace. Companies/entities set up server farms >> to just send out tons of email messages. (Defenders blacklist >> those servers.) 5. Those "servers" get distributed into >> massive botnets and are then able to avoid blacklisting, etc. >> >> I have absolutely no doubt that SIP spam will unfortunately >> follow the exact same trajectory. We're already seeing the >> tools to automate SPIT (here's one: >> http://www.hackingvoip.com/tools/spitter.tar.gz ). At some >> point we will hit my #4 when there are enough people using >> SIP *with publicly accessible SIP addresses* that it becomes >> financially lucrative enough for the larger automation to >> occur - and following on the heels of that will be the >> botnets. It will happen. To me it's not a question of IF >> but rather WHEN. >> >> Right now, though, we're still in my steps 1-3 as people >> start to get SIP endpoints and realize how they can abuse them. >> >> My concern about adding the focus on botnets into RUCUS is >> the fact that we can easily get distracted into looking at >> how to solve bigger issues and not get done the smaller >> issues that we can perhaps address today. >> >> Let's face it, probably all of us on this list would be >> categorized as early adopters who like to explore cutting >> edge technologies. We like to chase bright shiny objects and >> what is new and sexy and interesting. Let's say that you >> have a choice at the next IETF to listen to either: >> 1. a presentation on a SIP header to pass a "spam score" >> value between a SIP proxy and a UA; or 2. a presentation >> about SIP botnets, how they are constructed and the threats they >> pose. >> I would expect that probably 90% of us would choose the >> botnet talk. (No disrespect intended to the spam-score folks, >> just using an example.) The reality, though, is that the spam >> score discussion might be far more useful in moving us toward >> solutions that will help us with the people abusing SIP >> systems today. I don't want to wake up some day and find out >> that while we've been having a ton of discussions about >> botnets, some idiot meanwhile is repeatedly connecting to my >> SIP server and pumping our voicemail system full of SPIT. >> >> Maybe it's crazy on my part, but I want to see RUCUS have a >> charter that results in an achievable plan and architecture. >> >> Yes, we should consider botnets as a potential source of SIP >> spam and, yes, the potential existence of SIP botnets should >> be included in our thinking about an architecture to address >> SIP spam (so that any architecture we come up with does not >> discount dealing with botnets). But I also think we need to >> stay focused on what we can do now about the threats that are >> out there today (before it's too late). Let's crawl first, >> then walk, then run. >> >> My 2 cents, >> Dan >> >> On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: >> >> Today, most of the spam email comes from bot-nets and recently >> email spammers started to send massively from compromized >> valid email accounts. I do not see why this would not become >> also the biggest source of SIP spam in the future. >> >> Consequently, we should address this issue when developing an >> architecture for reducing SIP spam in the RUCUS WG. The >> architecture should be general enough for covering also means >> that reduce SIP spam from bot nets and compromized accounts >> >> Whether or not to work on this problem is being discussed >> highly controversially in the IETF. But considering that the >> RUCUS BoF is targeted at establishing not a regular working >> group, but an RFC 5111 Exploratory Group, I do not think it >> would be appropriate to exclude such work from the beginning. >> >> It should rather be part of the exploratory work to find out >> whether or not reducing SIP spam from bot nets is a target >> worth to be attacked by the IETF. >> >> >> -- >> Dan York, CISSP, Director of Emerging Communication Technology >> Office of the CTO Voxeo Corporation dyork@voxeo.com >> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >> >> Bring your web applications to the phone. >> Find out how at http://evolution.voxeo.com >> >> >> >> >> > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-176--263850768 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Saverio,

Point = taken. =A0Count me as one who will look forward to the primer at the = beginning of the RUCUS session about Exploratory Groups and their = differentiation from Working Groups.

I guess my concern is that = we've been doing a whole lot of "exploration" of the whole area of SIP = spam/SPIT for several years, as can been seen by the numerous drafts = that have been written by a host of folks on this list (including = yourself) as well as RFC 5039. =A0Admittedly, and perhaps this is the = key point, the exploration has been done in an *unstructured* way as = people investigated topics related to SPIT that were of interest to = them. =A0The role of the RUCUS "EG" may be to provide the *structure* = for that continued exploration.

I do, though, believe that = we do need to move as best we can toward identifying the key actions we = can start to take and the guidance we can start to give people for how = to potentially address the issue. =A0Hence my interest in an achievable = plan and architecture. =A0I don't know when that magic point will be = when we start seeing large volumes of SIP spam, but given as RFC 5039 = points out: "Don't Wait Until It's Too Late". (And we know that any = proposals we develop *do* take time to be first standardized and then = actually deployed.)

Thanks for the = feedback,
Dan

On Feb 20, 2008, at 9:35 = AM, Saverio Niccolini wrote:

Hi,

just a small comment, RFC 5111 = says:
"the goal of an Exploratory = Group is to put in place the
prerequisites = for formation of a Working Group"

Thus I do not think we should = start excluding any direction
from the = beginning, we are here to explore. RUCUS is not going
to be a normal WG but an exploratory one.

We = should think of an architecture that is able to accomodate
many potential building blocks.

If, = after the approval of RUCUS and during its lifetime, we = realize
that some building blocks do not = fit the big picture then we can drop
them. But not = exclude them a priori.
Saverio

Dr. Saverio = Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research = Division =
Kurfuerstenanlage 36, D-69115 = Heidelberg
Tel. =A0 =A0 +49 (0)6221 = 4342-118
Fax: =A0 =A0 +49 (0)6221 = 4342-155
e-mail:=A0 saverio.niccolini@nw.neclab= .eu <-- !!! NEW ADDRESS !!!
NEC Europe = Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England = 2832014



-----Original Message-----
Sent: Tuesday, February 19, 2008 9:24 PM
To: Juergen Quittek
Cc: rucus@ietf.org; Signaling TO Prevent = SPIT
Subject: [spitstop] Botnets, = take 2... Re: [Rucus] Draft RUCUS charter

Juergen (and = Saverio and others),
I appreciate the point you are = raising here.=A0 My = interest and=A0
passion are in networking, communication and = security.=A0 To=A0
me, = botnets are both incredibly fascinating and incredibly=A0
=A0 I agree = with you that botnets very certainly may=A0
be the = biggest source of SIP spam in the future.

Here's my = problem:

=A0=A0 =A0 = We have to crawl before we can walk and before we can = run.

Let's say that this is the (incredibly simplistic = view of=A0
the) evolution of email spam:

1. = Someone figures out that they can send advertisements to a=A0
range of = email addresses they have collected.
2. Someone = realizes that they can add those addresses to a=A0
"mailing = list" to easily send to a large number of addresses.
3. Tools are developed that automate the collection = of=A0
addresses and the sending out of messages.
4. At a certain time, there are enough people using = email out=A0
there that this whole area of email advertising is a = huge=A0
financial marketplace. Companies/entities set up = server farms=A0
to just send out tons of email messages. (Defenders = blacklist=A0
those servers.) 5. Those "servers" get distributed = into=A0
massive botnets and are then able to avoid = blacklisting, etc.
I have absolutely no doubt that = SIP spam will unfortunately=A0
follow = the exact same trajectory. We're already seeing the=A0
tools to = automate SPIT (here's one:=A0
point we = will hit my #4 when there are enough people using=A0
SIP = *with publicly accessible SIP addresses* that it becomes=A0
=A0
occur - = and following on the heels of that will be the=A0
=A0 It will = happen.=A0 To me it's not a = question of IF=A0
but rather WHEN.

Right now, though, we're still = in my steps 1-3 as people=A0
start to = get SIP endpoints and realize how they can abuse them.

My = concern about adding the focus on botnets into RUCUS is=A0
the fact = that we can easily get distracted into looking at=A0
how to = solve bigger issues and not get done the smaller=A0
issues = that we can perhaps address today.

Let's face it, probably all of = us on this list would be=A0
=A0
edge = technologies.=A0 We like to = chase bright shiny objects and=A0
what is = new and sexy and interesting.=A0 = Let's say that you=A0
have a = choice at the next IETF to listen to either:
1. a presentation on a SIP header to pass a "spam = score"=A0
value between a SIP proxy and a UA; or 2. a = presentation=A0
about SIP botnets, how they are constructed and the = threats they pose.
I would expect that = probably 90% of us would choose the=A0
botnet = talk. (No disrespect intended to the spam-score folks,=A0
just = using an example.) The reality, though, is that the spam=A0
score = discussion might be far more useful in moving us toward=A0
=A0
systems = today.=A0 I don't want to = wake up some day and find out=A0
that = while we've been having a ton of discussions about=A0
botnets, = some idiot meanwhile is repeatedly connecting to my=A0
SIP = server and pumping our voicemail system full of SPIT.

Maybe = it's crazy on my part, but I want to see RUCUS have a=A0
charter = that results in an achievable plan and architecture.

Yes, we = should consider botnets as a potential source of SIP=A0
spam = and, yes, the potential existence of SIP botnets should=A0
be = included in our thinking about an architecture to address=A0
SIP spam = (so that any architecture we come up with does not=A0
discount = dealing with botnets).=A0 = But I also think we need to=A0
stay = focused on what we can do now about the threats that are=A0
out = there today (before it's too late). =A0 Let's crawl first,=A0
then = walk, then run.

My 2 cents,
Dan

On Feb = 19, 2008, at 11:51 AM, Juergen Quittek wrote:

Today, = most of the spam email comes from bot-nets and recently
email spammers started to send = massively from compromized
valid = email accounts.=A0 I do not = see why this would not become
also the = biggest source of SIP spam in the future.

= Consequently, we should address this issue when developing = an
architecture for reducing SIP = spam in the RUCUS WG.=A0 = The
architecture should be general = enough for covering also means
that = reduce SIP spam from bot nets and compromized accounts

Whether = or not to work on this problem is being discussed
highly controversially in the = IETF. But considering that the
RUCUS BoF = is targeted at establishing not a regular working
group, but an RFC 5111 = Exploratory Group, I do not think it
would be = appropriate to exclude such work from the beginning.

It should = rather be part of the exploratory work to find out
whether or not reducing SIP spam = from bot nets is a target
worth to = be attacked by the IETF.


--
Dan York, CISSP, Director = of Emerging Communication Technology
Office of the = CTO=A0 =A0 Voxeo = Corporation =A0 =A0 dyork@voxeo.com
Phone: +1-407-455-5859=A0 Skype: danyork=A0 http://www.voxeo.com

Bring your web applications to the phone.





Rucus mailing list

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=
= --Apple-Mail-176--263850768-- --===============0892122257== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============0892122257==-- From rucus-bounces@ietf.org Wed Feb 20 10:14:12 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A447128C259; Wed, 20 Feb 2008 10:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHABzDPAQv0r; Wed, 20 Feb 2008 10:14:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C370028C1F7; Wed, 20 Feb 2008 10:14:10 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B413D3A6E46 for ; Wed, 20 Feb 2008 10:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbFaFSVAi9sa for ; Wed, 20 Feb 2008 10:14:08 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 735203A6E49 for ; Wed, 20 Feb 2008 10:14:08 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 20 Feb 2008 10:14:05 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1KIE5pZ012634; Wed, 20 Feb 2008 10:14:05 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1KIE2Jg016344; Wed, 20 Feb 2008 18:14:02 GMT From: "Dan Wing" To: "'Fischer, Kai'" , , "'Juergen Quittek'" References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <198A10EC585EC74687BCA414E2A5971802093A04@MCHP7RDA.ww002.siemens.net> Date: Wed, 20 Feb 2008 10:14:06 -0800 Message-ID: <103301c873ec$61f80760$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <198A10EC585EC74687BCA414E2A5971802093A04@MCHP7RDA.ww002.siemens.net> Thread-Index: AchzNVa8Vbt2xm67QgS+RRpF0kzNNgAaZhswABJWqDA= Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Signaling TO Prevent SPIT' Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Fischer, Kai > Sent: Wednesday, February 20, 2008 1:21 AM > To: rucus@ietf.org; Juergen Quittek > Cc: Signaling TO Prevent SPIT > Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft > RUCUS charter > > Hi, > I think, in the past discussions two different issues (botnet and > identity theft) are combined, but need to be discussed / addressed > separately. > > Most people consider with the term 'botnet' a number of > captured hosts, > which will be used for attacks like DoS, SPAM or SPIT. They are using > the IP address identity of the captured host but not usually the > authenticated application identity. Here, mechanism like DKIM > for email > SPAM or other approaches can counter such threats. > > Identity theft is even more challenging to solve regardless > if an attack > is initiated by a single captured host or in worst case a botnet of > captured host including identity thefts. That is an excellent separation. -d > Kai > > ________________________________ > > From: spitstop-bounces@listserv.netlab.nec.de > [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of Dan York > Sent: Dienstag, 19. Februar 2008 21:24 > To: Juergen Quittek > Cc: rucus@ietf.org; Signaling TO Prevent SPIT > Subject: [spitstop] Botnets, take 2... Re: [Rucus] Draft RUCUS > charter > > > Juergen (and Saverio and others), > > I appreciate the point you are raising here. My interest and > passion are in networking, communication and security. To me, botnets > are both incredibly fascinating and incredibly terrifying. I > agree with > you that botnets very certainly may be the biggest source of > SIP spam in > the future. > > Here's my problem: > > We have to crawl before we can walk and before we can run. > > Let's say that this is the (incredibly simplistic view of the) > evolution of email spam: > > 1. Someone figures out that they can send advertisements to a > range of email addresses they have collected. > 2. Someone realizes that they can add those addresses to a > "mailing list" to easily send to a large number of addresses. > 3. Tools are developed that automate the collection of addresses > and the sending out of messages. > 4. At a certain time, there are enough people using email out > there that this whole area of email advertising is a huge financial > marketplace. Companies/entities set up server farms to just send out > tons of email messages. (Defenders blacklist those servers.) > 5. Those "servers" get distributed into massive botnets and are > then able to avoid blacklisting, etc. > > I have absolutely no doubt that SIP spam will unfortunately > follow the exact same trajectory. We're already seeing the tools to > automate SPIT (here's one: > http://www.hackingvoip.com/tools/spitter.tar.gz ). At some point we > will hit my #4 when there are enough people using SIP *with publicly > accessible SIP addresses* that it becomes financially lucrative enough > for the larger automation to occur - and following on the > heels of that > will be the botnets. It will happen. To me it's not a question of IF > but rather WHEN. > > Right now, though, we're still in my steps 1-3 as people start > to get SIP endpoints and realize how they can abuse them. > > My concern about adding the focus on botnets into RUCUS is the > fact that we can easily get distracted into looking at how to solve > bigger issues and not get done the smaller issues that we can perhaps > address today. > > Let's face it, probably all of us on this list would be > categorized as early adopters who like to explore cutting edge > technologies. We like to chase bright shiny objects and what > is new and > sexy and interesting. Let's say that you have a choice at > the next IETF > to listen to either: > 1. a presentation on a SIP header to pass a "spam score" value > between a SIP proxy and a UA; or > 2. a presentation about SIP botnets, how they are constructed > and the threats they pose. > I would expect that probably 90% of us would choose the botnet > talk. (No disrespect intended to the spam-score folks, just using an > example.) The reality, though, is that the spam score discussion might > be far more useful in moving us toward solutions that will > help us with > the people abusing SIP systems today. I don't want to wake > up some day > and find out that while we've been having a ton of discussions about > botnets, some idiot meanwhile is repeatedly connecting to my > SIP server > and pumping our voicemail system full of SPIT. > > Maybe it's crazy on my part, but I want to see RUCUS have a > charter that results in an achievable plan and architecture. > > Yes, we should consider botnets as a potential source of SIP > spam and, yes, the potential existence of SIP botnets should > be included > in our thinking about an architecture to address SIP spam (so that any > architecture we come up with does not discount dealing with botnets). > But I also think we need to stay focused on what we can do > now about the > threats that are out there today (before it's too late). Let's crawl > first, then walk, then run. > > My 2 cents, > Dan > > On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: > > Today, most of the spam email comes from bot-nets and > recently > email spammers started to send massively from > compromized > valid email accounts. I do not see why this would not > become > also the biggest source of SIP spam in the future. > > Consequently, we should address this issue when > developing an > architecture for reducing SIP spam in the RUCUS WG. The > architecture should be general enough for covering also > means > that reduce SIP spam from bot nets and compromized > accounts > > Whether or not to work on this problem is being > discussed > highly controversially in the IETF. But considering that > the > RUCUS BoF is targeted at establishing not a regular > working > group, but an RFC 5111 Exploratory Group, I do not think > it > would be appropriate to exclude such work from the > beginning. > > It should rather be part of the exploratory work to find > out > whether or not reducing SIP spam from bot nets is a > target > worth to be attacked by the IETF. > > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com > http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 03:01:05 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EAEA3A6CBF; Fri, 22 Feb 2008 03:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_27=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uhyqU4Qk6eg; Fri, 22 Feb 2008 03:01:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE763A6CA7; Fri, 22 Feb 2008 03:01:04 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625793A6CA1 for ; Fri, 22 Feb 2008 03:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGjjfBzk8lI5 for ; Fri, 22 Feb 2008 03:01:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AD3E228C254 for ; Fri, 22 Feb 2008 03:01:01 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 11:00:56 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp045) with SMTP; 22 Feb 2008 12:00:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1978I9tZ7h7GFig2OC2O+RFgDwuI6YLROEF9HIq71 /Xu+V7aw/B3fV9 Message-ID: <47BEAB65.3040104@gmx.net> Date: Fri, 22 Feb 2008 13:00:53 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Juergen, Juergen Quittek wrote: > Hi Hannes, > > On 19.02.2008 19:57 Uhr "Hannes Tschofenig" > wrote: > > >> Hi Juergen, >> >> thanks for your feedback. >> >> The current charter proposal does not say indicate that >> >> - Strong Identity >> - White Lists >> - Solve the Introduction Problem >> - Don't Wait Until It's Too Late >> >> are the solution to the problem; it just indicates what RFC 5039 says. >> >> I do,however, agree with you that we should explicitly indicate that we >> want to explore different architectural approaches. Even though white >> lists are quite common in today's instant messaging world they are more >> or less unknown in the PSTN. The user's behavior will be quite important >> to understand with some of these different approaches. >> > > I fully agree. This is an important study item. > > >> I agree that looking at botnets and similar mechanisms is useful. Still, >> I would avoid the term "open Internet" since it is somewhat fuzzy. >> > > Yes, there may be better terms. I just would like to express, that > outside of well protected environment, there may be a need for means > beyond strong identities and white lists. And these should be > investigated by the RUCUS EG. > > I understand your motivation. >> Regarding your paragraph: >> " >> Strong identities and white lists will be essential in a well >> protected environment but do not solve the problem in the open >> Internet. In the open Internet compromised accounts and bot-nets >> are the major source of email spam today and expected to be the >> major source of SIP spam in the future. >> " >> >> We might need to ask the DKIM folks to better understand the current >> state of the art in email spam. For example: Are compromised accounts >> really a major source of email spam today? >> > > Well, using 'compromized hosts' as you do below would be fine. > We can investigate the relevance of compromized accounts when > RUCUS is established. (In Germany leading IT journals reported > today that compromized accounts are becoming relevant for email spam.) > > The solution space for dealing with compromised hosts can become pretty large. I fear that we extend the work without bounds. BUT: I do believe there is value in discussing this in the architecture phase even when we then have to conclude that most of the work that needs to be happening does not really belong in the IETF. >> FROM: >> The architecture will be >> general to cover a range of scenarios including well protected >> environment as well as the open Internet. >> >> >> TO: >> The architectural investigations should cover different threat >> models, including those of compromised end hosts. >> > > That's fine and probably less controversial. > > >> You wrote: >> " >> Out of the scope; >> >> -- PSTN replacement >> -- concrete algorithms for SIP spam prevention >> " >> >> I agree with the second one but what exactly have you had in mind with >> PSTN replacement in this context? >> > > Sorry, these were my notes what to exclude. > But it is not yet elaborated. > > OK. Ciao Hannes >> Ciao >> Hannes >> > > Thanks, > > Juergen > > >> Juergen Quittek wrote: >> >>> Dear all, >>> >>> I had a look at the draft charter that Hannes set up on his RUCUS >>> web page and I think it is targeting the right direction. However, >>> I suggest extending the scope and have attached a modified version >>> of the draft charter below. >>> >>> My only major problem with the current version is that it fully >>> builds on the recommendations given in RFC 5039, namely >>> >>> - Strong Identity >>> - White Lists >>> - Solve the Introduction Problem >>> - Don't Wait Until It's Too Late >>> >>> I do not think that these approaches are wrong, but that they >>> do not cover what I consider to be the most important issue in >>> reducing SIP spam. >>> >>> Today, most of the spam email comes from bot-nets and recently >>> email spammers started to send massively from compromized >>> valid email accounts. I do not see why this would not become >>> also the biggest source of SIP spam in the future. >>> >>> Consequently, we should address this issue when developing an >>> architecture for reducing SIP spam in the RUCUS WG. The >>> architecture should be general enough for covering also means >>> that reduce SIP spam from bot nets and compromized accounts >>> >>> Whether or not to work on this problem is being discussed >>> highly controversially in the IETF. But considering that the >>> RUCUS BoF is targeted at establishing not a regular working >>> group, but an RFC 5111 Exploratory Group, I do not think it >>> would be appropriate to exclude such work from the beginning. >>> >>> It should rather be part of the exploratory work to find out >>> whether or not reducing SIP spam from bot nets is a target >>> worth to be attacked by the IETF. >>> >>> Below please find my suggestion for extending the charter. >>> Main differences to the current draft are the new third >>> paragraph (starting with "Strong identities ...") and some >>> additions to the end of the fifth paragraph. >>> >>> Thanks, >>> >>> Juergen >>> >>> >>> ==================== >>> >>> The Session Initiation Protocol (SIP) defines a system for >>> user-to-user multimedia communications. Therefore, it is >>> susceptible to unwanted communication attempts. RFC 5039 >>> analyzes the problem of spam in SIP and examines various >>> possible solutions that have been discussed for email and >>> considers their applicability to SIP. >>> >>> RFC 5039 gives good, high-level recommendations regarding >>> future work, namely >>> >>> * Strong Identity >>> * White Lists >>> * Solve the Introduction Problem >>> * Don't Wait Until It's Too Late >>> >>> Strong identities and white lists will be essential in a well >>> protected environment but do not solve the problem in the open >>> Internet. In the open Internet compromised accounts and bot-nets >>> are the major source of email spam today and expected to be the >>> major source of SIP spam in the future. >>> >>> Among the many individual solution building blocks that are >>> discussed in RFC 5039 (including content filtering, black lists, >>> white lists, consent-based communication, reputation systems, >>> address obfuscation, limited use addresses, turing tests, >>> computational puzzles, payments at risk, circles of trust, and >>> many others) there is no framework outlined how various >>> mechanisms work together to produce a complete solution nor >>> does the document attempt to offer a ranking to determine >>> which solutions could form an initial set of candidate for >>> subsequent standardization. >>> >>> This exploratory group chartered for one year aims to create a >>> venue where discussions on unwanted communication in SIP can >>> take place. The main goal of the group is to produce an >>> architecture document that outlines the interworking between >>> identified potential building blocks. The architecture will be >>> general to cover a range of scenarios including well protected >>> environment as well as the open Internet. >>> >>> The group will consider prior work on SIP identity and related >>> techniques and will consult with privacy experts to deal with >>> the legal aspects of filtering communication attempts. >>> >>> Out of the scope; >>> -- PSTN replacement >>> -- concrete algorithms for SIP spam prevention >>> >>> _______________________________________________ >>> Rucus mailing list >>> Rucus@ietf.org >>> http://www.ietf.org/mailman/listinfo/rucus >>> >>> _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 03:06:14 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B230328C2A0; Fri, 22 Feb 2008 03:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjDZM0TryWw3; Fri, 22 Feb 2008 03:06:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960CA3A6C41; Fri, 22 Feb 2008 03:06:13 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477F93A6B7B for ; Fri, 22 Feb 2008 03:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwjSnmIKdVtP for ; Fri, 22 Feb 2008 03:06:11 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7F9033A6C41 for ; Fri, 22 Feb 2008 03:06:10 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 11:06:05 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp016) with SMTP; 22 Feb 2008 12:06:05 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ABFkz4H5AMLgvI3GSu27oilRfLBh82HDqHNrFEs QpRi32BrKeCy2e Message-ID: <47BEAC97.6050400@gmx.net> Date: Fri, 22 Feb 2008 13:05:59 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Signaling TO Prevent SPIT References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <198A10EC585EC74687BCA414E2A5971802093A04@MCHP7RDA.ww002.siemens.net> In-Reply-To: <198A10EC585EC74687BCA414E2A5971802093A04@MCHP7RDA.ww002.siemens.net> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org, Juergen Quittek Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Kai, I believe it is useful to differentiate between these two cases. Martin and Juergen indicate that botnets using identity theft are already getting common. This would reduce the usefulness of white lists a bit. If such a botnet includes Alice's machine and her SIP UA calls me then this does not necessarily mean that my whitelist is ineffective; it would only be true if I Alice is in my buddy list. Ciao Hannes Fischer, Kai wrote: > Hi, > I think, in the past discussions two different issues (botnet and > identity theft) are combined, but need to be discussed / addressed > separately. > > Most people consider with the term 'botnet' a number of captured hosts, > which will be used for attacks like DoS, SPAM or SPIT. They are using > the IP address identity of the captured host but not usually the > authenticated application identity. Here, mechanism like DKIM for email > SPAM or other approaches can counter such threats. > > Identity theft is even more challenging to solve regardless if an attack > is initiated by a single captured host or in worst case a botnet of > captured host including identity thefts. > > Kai > > ________________________________ > > From: spitstop-bounces@listserv.netlab.nec.de > [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of Dan York > Sent: Dienstag, 19. Februar 2008 21:24 > To: Juergen Quittek > Cc: rucus@ietf.org; Signaling TO Prevent SPIT > Subject: [spitstop] Botnets, take 2... Re: [Rucus] Draft RUCUS > charter > > > Juergen (and Saverio and others), > > I appreciate the point you are raising here. My interest and > passion are in networking, communication and security. To me, botnets > are both incredibly fascinating and incredibly terrifying. I agree with > you that botnets very certainly may be the biggest source of SIP spam in > the future. > > Here's my problem: > > We have to crawl before we can walk and before we can run. > > Let's say that this is the (incredibly simplistic view of the) > evolution of email spam: > > 1. Someone figures out that they can send advertisements to a > range of email addresses they have collected. > 2. Someone realizes that they can add those addresses to a > "mailing list" to easily send to a large number of addresses. > 3. Tools are developed that automate the collection of addresses > and the sending out of messages. > 4. At a certain time, there are enough people using email out > there that this whole area of email advertising is a huge financial > marketplace. Companies/entities set up server farms to just send out > tons of email messages. (Defenders blacklist those servers.) > 5. Those "servers" get distributed into massive botnets and are > then able to avoid blacklisting, etc. > > I have absolutely no doubt that SIP spam will unfortunately > follow the exact same trajectory. We're already seeing the tools to > automate SPIT (here's one: > http://www.hackingvoip.com/tools/spitter.tar.gz ). At some point we > will hit my #4 when there are enough people using SIP *with publicly > accessible SIP addresses* that it becomes financially lucrative enough > for the larger automation to occur - and following on the heels of that > will be the botnets. It will happen. To me it's not a question of IF > but rather WHEN. > > Right now, though, we're still in my steps 1-3 as people start > to get SIP endpoints and realize how they can abuse them. > > My concern about adding the focus on botnets into RUCUS is the > fact that we can easily get distracted into looking at how to solve > bigger issues and not get done the smaller issues that we can perhaps > address today. > > Let's face it, probably all of us on this list would be > categorized as early adopters who like to explore cutting edge > technologies. We like to chase bright shiny objects and what is new and > sexy and interesting. Let's say that you have a choice at the next IETF > to listen to either: > 1. a presentation on a SIP header to pass a "spam score" value > between a SIP proxy and a UA; or > 2. a presentation about SIP botnets, how they are constructed > and the threats they pose. > I would expect that probably 90% of us would choose the botnet > talk. (No disrespect intended to the spam-score folks, just using an > example.) The reality, though, is that the spam score discussion might > be far more useful in moving us toward solutions that will help us with > the people abusing SIP systems today. I don't want to wake up some day > and find out that while we've been having a ton of discussions about > botnets, some idiot meanwhile is repeatedly connecting to my SIP server > and pumping our voicemail system full of SPIT. > > Maybe it's crazy on my part, but I want to see RUCUS have a > charter that results in an achievable plan and architecture. > > Yes, we should consider botnets as a potential source of SIP > spam and, yes, the potential existence of SIP botnets should be included > in our thinking about an architecture to address SIP spam (so that any > architecture we come up with does not discount dealing with botnets). > But I also think we need to stay focused on what we can do now about the > threats that are out there today (before it's too late). Let's crawl > first, then walk, then run. > > My 2 cents, > Dan > > On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: > > Today, most of the spam email comes from bot-nets and > recently > email spammers started to send massively from > compromized > valid email accounts. I do not see why this would not > become > also the biggest source of SIP spam in the future. > > Consequently, we should address this issue when > developing an > architecture for reducing SIP spam in the RUCUS WG. The > architecture should be general enough for covering also > means > that reduce SIP spam from bot nets and compromized > accounts > > Whether or not to work on this problem is being > discussed > highly controversially in the IETF. But considering that > the > RUCUS BoF is targeted at establishing not a regular > working > group, but an RFC 5111 Exploratory Group, I do not think > it > would be appropriate to exclude such work from the > beginning. > > It should rather be part of the exploratory work to find > out > whether or not reducing SIP spam from bot nets is a > target > worth to be attacked by the IETF. > > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com > http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > > > _______________________________________________ > spitstop mailing list > spitstop@listserv.netlab.nec.de > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 03:06:31 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9D4628C2CC; Fri, 22 Feb 2008 03:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVTyycdBehFB; Fri, 22 Feb 2008 03:06:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB3228C2A8; Fri, 22 Feb 2008 03:06:30 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A4F28C218 for ; Fri, 22 Feb 2008 03:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWJwori74aNS for ; Fri, 22 Feb 2008 03:06:27 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C897128C224 for ; Fri, 22 Feb 2008 03:06:22 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 11:06:17 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp009) with SMTP; 22 Feb 2008 12:06:17 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18lghcIXFclNoQomRAJgxL47f4txMuZFQ1rnJvkxs hjtrvPHvwDo/fZ Message-ID: <47BEACA5.8060908@gmx.net> Date: Fri, 22 Feb 2008 13:06:13 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Azzopardi References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> In-Reply-To: <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org, Signaling TO Prevent SPIT , Juergen Quittek Subject: Re: [Rucus] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Do you have some ideas on what should be done against botnets? Just wondering.... Ciao Hannes Brian Azzopardi wrote: > Dan, > > > > I am afraid that we may have to hit the ground running. Email spam is > already a big industry with well established operators. Spewing out SPIT > instead of email spam is just another 'product' for them. Only amateur > SPITers will use spitter and other such tools - the professional ones > already have the infrastructure in place and they'd be irrational not to > reuse it for SPIT - they will just short-circuit to your step 5. We do > need to think deeply about botnets - they are the principal means of > sending spam and have been for at least the last 2 years. > > > > Regards, > > > > Brian Azzopardi - Senior Business Analyst > > GFI Software - www.gfi.com > > > > > > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf > Of Dan York > Sent: 19 February 2008 21:24 > To: Juergen Quittek > Cc: rucus@ietf.org; Signaling TO Prevent SPIT > Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter > > > > Juergen (and Saverio and others), > > > > I appreciate the point you are raising here. My interest and passion > are in networking, communication and security. To me, botnets are both > incredibly fascinating and incredibly terrifying. I agree with you that > botnets very certainly may be the biggest source of SIP spam in the > future. > > > > Here's my problem: > > > > We have to crawl before we can walk and before we can run. > > > > Let's say that this is the (incredibly simplistic view of the) evolution > of email spam: > > > > 1. Someone figures out that they can send advertisements to a range of > email addresses they have collected. > > 2. Someone realizes that they can add those addresses to a "mailing > list" to easily send to a large number of addresses. > > 3. Tools are developed that automate the collection of addresses and the > sending out of messages. > > 4. At a certain time, there are enough people using email out there that > this whole area of email advertising is a huge financial marketplace. > Companies/entities set up server farms to just send out tons of email > messages. (Defenders blacklist those servers.) > > 5. Those "servers" get distributed into massive botnets and are then > able to avoid blacklisting, etc. > > > > I have absolutely no doubt that SIP spam will unfortunately follow the > exact same trajectory. We're already seeing the tools to automate SPIT > (here's one: http://www.hackingvoip.com/tools/spitter.tar.gz ). At some > point we will hit my #4 when there are enough people using SIP *with > publicly accessible SIP addresses* that it becomes financially lucrative > enough for the larger automation to occur - and following on the heels > of that will be the botnets. It will happen. To me it's not a question > of IF but rather WHEN. > > > > Right now, though, we're still in my steps 1-3 as people start to get > SIP endpoints and realize how they can abuse them. > > > > My concern about adding the focus on botnets into RUCUS is the fact that > we can easily get distracted into looking at how to solve bigger issues > and not get done the smaller issues that we can perhaps address today. > > > > Let's face it, probably all of us on this list would be categorized as > early adopters who like to explore cutting edge technologies. We like > to chase bright shiny objects and what is new and sexy and interesting. > Let's say that you have a choice at the next IETF to listen to either: > > 1. a presentation on a SIP header to pass a "spam score" value between a > SIP proxy and a UA; or > > 2. a presentation about SIP botnets, how they are constructed and the > threats they pose. > > I would expect that probably 90% of us would choose the botnet talk. (No > disrespect intended to the spam-score folks, just using an example.) The > reality, though, is that the spam score discussion might be far more > useful in moving us toward solutions that will help us with the people > abusing SIP systems today. I don't want to wake up some day and find > out that while we've been having a ton of discussions about botnets, > some idiot meanwhile is repeatedly connecting to my SIP server and > pumping our voicemail system full of SPIT. > > > > Maybe it's crazy on my part, but I want to see RUCUS have a charter that > results in an achievable plan and architecture. > > > > Yes, we should consider botnets as a potential source of SIP spam and, > yes, the potential existence of SIP botnets should be included in our > thinking about an architecture to address SIP spam (so that any > architecture we come up with does not discount dealing with botnets). > But I also think we need to stay focused on what we can do now about the > threats that are out there today (before it's too late). Let's crawl > first, then walk, then run. > > > > My 2 cents, > > Dan > > > > On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: > > Today, most of the spam email comes from bot-nets and recently > > email spammers started to send massively from compromized > > valid email accounts. I do not see why this would not become > > also the biggest source of SIP spam in the future. > > > > Consequently, we should address this issue when developing an > > architecture for reducing SIP spam in the RUCUS WG. The > > architecture should be general enough for covering also means > > that reduce SIP spam from bot nets and compromized accounts > > > > Whether or not to work on this problem is being discussed > > highly controversially in the IETF. But considering that the > > RUCUS BoF is targeted at establishing not a regular working > > group, but an RFC 5111 Exploratory Group, I do not think it > > would be appropriate to exclude such work from the beginning. > > > > It should rather be part of the exploratory work to find out > > whether or not reducing SIP spam from bot nets is a target > > worth to be attacked by the IETF. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 03:16:00 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551E328C752; Fri, 22 Feb 2008 03:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaWVZQiUN9eu; Fri, 22 Feb 2008 03:16:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99F03A6CA7; Fri, 22 Feb 2008 03:15:58 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B8928C315 for ; Fri, 22 Feb 2008 03:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkQGatYFHrFu for ; Fri, 22 Feb 2008 03:15:56 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0C0CF3A6C89 for ; Fri, 22 Feb 2008 03:15:54 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 11:15:49 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp021) with SMTP; 22 Feb 2008 12:15:49 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Wx4R5yPsWTygA2nTs67RFpAt9SAKmCokLRonHd1 jAiFBrtxg3mYtJ Message-ID: <47BEAEE3.4040701@gmx.net> Date: Fri, 22 Feb 2008 13:15:47 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Signaling TO Prevent SPIT References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> <909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu> In-Reply-To: <909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org, Juergen Quittek Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org I think we should put Henning's classification somewhere in our documents. I had a chat with Peter Saint-Andre this week and he reported me about = problems they had with malicious users (potentially using the XMPP = servers for file sharing) in their XMPP server infrastructure. He told = me that their community is looking into a mechanism to allow one domain = to report problems to another domain. This would correspond to Henning's = 2nd category below and a mechanisms similar to the one described in = http://www.ietf.org/internet-drafts/draft-niccolini-sipping-spam-feedback-0= 0.txt = would be useful (expect that it would not be run between the end host = and the VoIP provider but between two VoIP providers). Ciao Hannes PS: I put Peter on CC in case I misunderstood something. Henning Schulzrinne wrote: > There are three sub-cases of bot nets: > > - Just uses host, without credentials: identity-based whitelisting = > works (subject to the usual problems with whitelisting) > > - Uses credentials, but spews randomly: unlikely that the recipient = > will have that person in their whitelist, so still manageable. > > - Uses credentials, spams addresses in addressbook: whitelists don't = > help, but at least the sender can be identified and fixed/fined/taken = > offline. > > I'm not trying to downplay bot nets, just that this is a bit more = > nuanced. > > Henning > > On Feb 20, 2008, at 3:37 AM, Brian Azzopardi wrote: > > = >> Dan, >> >> I am afraid that we may have to hit the ground running. Email spam = >> is already a big industry with well established operators. Spewing = >> out SPIT instead of email spam is just another =91product=92 for them. = >> Only amateur SPITers will use spitter and other such tools =96 the = >> professional ones already have the infrastructure in place and = >> they=92d be irrational not to reuse it for SPIT =96 they will just short= - = >> circuit to your step 5. We do need to think deeply about botnets =96 = >> they are the principal means of sending spam and have been for at = >> least the last 2 years. >> >> Regards, >> >> Brian Azzopardi - Senior Business Analyst >> GFI Software - www.gfi.com >> >> >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On = >> Behalf Of Dan York >> Sent: 19 February 2008 21:24 >> To: Juergen Quittek >> Cc: rucus@ietf.org; Signaling TO Prevent SPIT >> Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter >> >> Juergen (and Saverio and others), >> >> I appreciate the point you are raising here. My interest and = >> passion are in networking, communication and security. To me, = >> botnets are both incredibly fascinating and incredibly terrifying. = >> I agree with you that botnets very certainly may be the biggest = >> source of SIP spam in the future. >> >> Here's my problem: >> >> We have to crawl before we can walk and before we can run. >> >> Let's say that this is the (incredibly simplistic view of the) = >> evolution of email spam: >> >> 1. Someone figures out that they can send advertisements to a range = >> of email addresses they have collected. >> 2. Someone realizes that they can add those addresses to a "mailing = >> list" to easily send to a large number of addresses. >> 3. Tools are developed that automate the collection of addresses and = >> the sending out of messages. >> 4. At a certain time, there are enough people using email out there = >> that this whole area of email advertising is a huge financial = >> marketplace. Companies/entities set up server farms to just send out = >> tons of email messages. (Defenders blacklist those servers.) >> 5. Those "servers" get distributed into massive botnets and are then = >> able to avoid blacklisting, etc. >> >> I have absolutely no doubt that SIP spam will unfortunately follow = >> the exact same trajectory. We're already seeing the tools to = >> automate SPIT (here's one: http://www.hackingvoip.com/tools/spitter.tar.= gz = >> ). At some point we will hit my #4 when there are enough people = >> using SIP *with publicly accessible SIP addresses* that it becomes = >> financially lucrative enough for the larger automation to occur - = >> and following on the heels of that will be the botnets. It will = >> happen. To me it's not a question of IF but rather WHEN. >> >> Right now, though, we're still in my steps 1-3 as people start to = >> get SIP endpoints and realize how they can abuse them. >> >> My concern about adding the focus on botnets into RUCUS is the fact = >> that we can easily get distracted into looking at how to solve = >> bigger issues and not get done the smaller issues that we can = >> perhaps address today. >> >> Let's face it, probably all of us on this list would be categorized = >> as early adopters who like to explore cutting edge technologies. We = >> like to chase bright shiny objects and what is new and sexy and = >> interesting. Let's say that you have a choice at the next IETF to = >> listen to either: >> 1. a presentation on a SIP header to pass a "spam score" value = >> between a SIP proxy and a UA; or >> 2. a presentation about SIP botnets, how they are constructed and = >> the threats they pose. >> I would expect that probably 90% of us would choose the botnet talk. = >> (No disrespect intended to the spam-score folks, just using an = >> example.) The reality, though, is that the spam score discussion = >> might be far more useful in moving us toward solutions that will = >> help us with the people abusing SIP systems today. I don't want to = >> wake up some day and find out that while we've been having a ton of = >> discussions about botnets, some idiot meanwhile is repeatedly = >> connecting to my SIP server and pumping our voicemail system full of = >> SPIT. >> >> Maybe it's crazy on my part, but I want to see RUCUS have a charter = >> that results in an achievable plan and architecture. >> >> Yes, we should consider botnets as a potential source of SIP spam = >> and, yes, the potential existence of SIP botnets should be included = >> in our thinking about an architecture to address SIP spam (so that = >> any architecture we come up with does not discount dealing with = >> botnets). But I also think we need to stay focused on what we can = >> do now about the threats that are out there today (before it's too = >> late). Let's crawl first, then walk, then run. >> >> My 2 cents, >> Dan >> >> On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: >> Today, most of the spam email comes from bot-nets and recently >> email spammers started to send massively from compromized >> valid email accounts. I do not see why this would not become >> also the biggest source of SIP spam in the future. >> >> Consequently, we should address this issue when developing an >> architecture for reducing SIP spam in the RUCUS WG. The >> architecture should be general enough for covering also means >> that reduce SIP spam from bot nets and compromized accounts >> >> Whether or not to work on this problem is being discussed >> highly controversially in the IETF. But considering that the >> RUCUS BoF is targeted at establishing not a regular working >> group, but an RFC 5111 Exploratory Group, I do not think it >> would be appropriate to exclude such work from the beginning. >> >> It should rather be part of the exploratory work to find out >> whether or not reducing SIP spam from bot nets is a target >> worth to be attacked by the IETF. >> >> -- = >> Dan York, CISSP, Director of Emerging Communication Technology >> Office of the CTO Voxeo Corporation dyork@voxeo.com >> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >> >> Bring your web applications to the phone. >> Find out how at http://evolution.voxeo.com >> >> >> >> >> >> >> DISCLAIMER >> The information contained in this electronic mail may be = >> confidential or legally privileged. It is for the intended = >> recipient(s) only. Should you receive this message in error, please = >> notify the sender by replying to this mail. Unless expressly stated, = >> opinions in this message are those of the individual sender and not = >> of GFI. Unauthorized use of the contents is strictly prohibited. = >> While all care has been taken, GFI is not responsible for the = >> integrity of the contents of this electronic mail and any = >> attachments included within. >> >> This mail was checked for viruses by GFI MailSecurity. GFI also = >> develops anti-spam software (GFI MailEssentials), a fax server (GFI = >> FAXmaker), and network security and management software (GFI = >> LANguard) - www.gfi.com >> >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> http://www.ietf.org/mailman/listinfo/rucus >> = > > _______________________________________________ > spitstop mailing list > spitstop@listserv.netlab.nec.de > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > = _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 03:33:27 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC783A6C79; Fri, 22 Feb 2008 03:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV1ILxziQRfk; Fri, 22 Feb 2008 03:33:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B04F3A6C47; Fri, 22 Feb 2008 03:33:26 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFFE3A6885 for ; Fri, 22 Feb 2008 03:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaKPLm+JeZbd for ; Fri, 22 Feb 2008 03:33:23 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C67AF3A6C64 for ; Fri, 22 Feb 2008 03:33:22 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 11:33:17 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp010) with SMTP; 22 Feb 2008 12:33:17 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/TZZs2wIDTURu0fQJiip+ihN92Hd4svo/VpsCGSo 0OTNYK4Yny5yXU Message-ID: <47BEB2FF.9060304@gmx.net> Date: Fri, 22 Feb 2008 13:33:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dan York References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <5F6519BF2DE0404D99B7C75607FF76FF4D11DA@mx1.office> <55DE3E54-6421-4632-AABE-D171D5D6E346@voxeo.com> In-Reply-To: <55DE3E54-6421-4632-AABE-D171D5D6E346@voxeo.com> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org, Saverio Niccolini Subject: Re: [Rucus] EG vs WG - Re: [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org I agree with Dan but at the same time I also agree with Saverio. Here is the issue: Difficult security challenges often require complicated solutions. The evil guy will pick the easy target's first. For me, an easy indication about the success of a specific technology is when you get the first spam. For example, when I look at my blog, Wiki, or roundup issue tracker then I have to admit that they are pretty successful on the Internet. Spammer exploit them. It would not make sense to target them if only a few folks use them. Hence, you raise the bar. Instead of allowing everyone to post comments and to register themself you put some additional mechanisms in place -- these mechanisms will typically be inconvenient for the users (for example, they have to go through a CAPTCHA test before posting something, posting is only allowed for members; I have to add them manually to the access control list, etc.). The XMPP experience tells us something about this already and they use an email alike style of communication (hence they don't even have something like SIP Identity). The simple techniques work fine at the beginning but you have to raise the bar for the adversary as your technology becomes more successful. Email Spammers could just easily use their existing botnets and apply them to XMPP; sure. They did not do it because it does not create enough revenue for them -- email, Wiki's and Weblogs are much better. It might sound ironic but we have to make sure that the evil guys pick someone else and not SIP. In our work we clearly need to differentiate between implementing and deploying it vs. writing documents. We can obviously quite easily write documents that address almost every problem we can imagine. That's not the issue. The challenge begins when all the stuff has to be deployed. When someone who hasn't followed IETF mailing list discussions suddenly sees 50 different mechanisms and extensions they will be confused. What should they do? They will not implement all; particularly not if they do not yet have a lot of problems. They will have to implement things incrementally. What should they start with? Ciao Hannes Dan York wrote: > Saverio, > > Point taken. Count me as one who will look forward to the primer at > the beginning of the RUCUS session about Exploratory Groups and their > differentiation from Working Groups. > > I guess my concern is that we've been doing a whole lot of > "exploration" of the whole area of SIP spam/SPIT for several years, as > can been seen by the numerous drafts that have been written by a host > of folks on this list (including yourself) as well as RFC 5039. > Admittedly, and perhaps this is the key point, the exploration has > been done in an *unstructured* way as people investigated topics > related to SPIT that were of interest to them. The role of the RUCUS > "EG" may be to provide the *structure* for that continued exploration. > > I do, though, believe that we do need to move as best we can toward > identifying the key actions we can start to take and the guidance we > can start to give people for how to potentially address the issue. > Hence my interest in an achievable plan and architecture. I don't > know when that magic point will be when we start seeing large volumes > of SIP spam, but given as RFC 5039 points out: "Don't Wait Until It's > Too Late". (And we know that any proposals we develop *do* take time > to be first standardized and then actually deployed.) > > Thanks for the feedback, > Dan > > On Feb 20, 2008, at 9:35 AM, Saverio Niccolini wrote: > >> Hi, >> >> just a small comment, RFC 5111 says: >> "the goal of an Exploratory Group is to put in place the >> prerequisites for formation of a Working Group" >> >> Thus I do not think we should start excluding any direction >> from the beginning, we are here to explore. RUCUS is not going >> to be a normal WG but an exploratory one. >> >> We should think of an architecture that is able to accomodate >> many potential building blocks. >> >> If, after the approval of RUCUS and during its lifetime, we realize >> that some building blocks do not fit the big picture then we can drop >> them. But not exclude them a priori. >> >> Saverio >> >> ============================================================ >> Dr. Saverio Niccolini >> Senior Researcher >> NEC Laboratories Europe, Network Research Division >> Kurfuerstenanlage 36, D-69115 Heidelberg >> Tel. +49 (0)6221 4342-118 >> Fax: +49 (0)6221 4342-155 >> e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! >> ============================================================ >> NEC Europe Limited Registered Office: NEC House, 1 Victoria >> Road, London W3 6BL Registered in England 2832014 >> >> >> >>> -----Original Message----- >>> From: spitstop-bounces@listserv.netlab.nec.de >>> [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of Dan York >>> Sent: Tuesday, February 19, 2008 9:24 PM >>> To: Juergen Quittek >>> Cc: rucus@ietf.org; Signaling TO Prevent SPIT >>> Subject: [spitstop] Botnets, take 2... Re: [Rucus] Draft RUCUS charter >>> >>> Juergen (and Saverio and others), >>> >>> I appreciate the point you are raising here. My interest and >>> passion are in networking, communication and security. To >>> me, botnets are both incredibly fascinating and incredibly >>> terrifying. I agree with you that botnets very certainly may >>> be the biggest source of SIP spam in the future. >>> >>> Here's my problem: >>> >>> We have to crawl before we can walk and before we can run. >>> >>> Let's say that this is the (incredibly simplistic view of >>> the) evolution of email spam: >>> >>> 1. Someone figures out that they can send advertisements to a >>> range of email addresses they have collected. >>> 2. Someone realizes that they can add those addresses to a >>> "mailing list" to easily send to a large number of addresses. >>> 3. Tools are developed that automate the collection of >>> addresses and the sending out of messages. >>> 4. At a certain time, there are enough people using email out >>> there that this whole area of email advertising is a huge >>> financial marketplace. Companies/entities set up server farms >>> to just send out tons of email messages. (Defenders blacklist >>> those servers.) 5. Those "servers" get distributed into >>> massive botnets and are then able to avoid blacklisting, etc. >>> >>> I have absolutely no doubt that SIP spam will unfortunately >>> follow the exact same trajectory. We're already seeing the >>> tools to automate SPIT (here's one: >>> http://www.hackingvoip.com/tools/spitter.tar.gz ). At some >>> point we will hit my #4 when there are enough people using >>> SIP *with publicly accessible SIP addresses* that it becomes >>> financially lucrative enough for the larger automation to >>> occur - and following on the heels of that will be the >>> botnets. It will happen. To me it's not a question of IF >>> but rather WHEN. >>> >>> Right now, though, we're still in my steps 1-3 as people >>> start to get SIP endpoints and realize how they can abuse them. >>> >>> My concern about adding the focus on botnets into RUCUS is >>> the fact that we can easily get distracted into looking at >>> how to solve bigger issues and not get done the smaller >>> issues that we can perhaps address today. >>> >>> Let's face it, probably all of us on this list would be >>> categorized as early adopters who like to explore cutting >>> edge technologies. We like to chase bright shiny objects and >>> what is new and sexy and interesting. Let's say that you >>> have a choice at the next IETF to listen to either: >>> 1. a presentation on a SIP header to pass a "spam score" >>> value between a SIP proxy and a UA; or 2. a presentation >>> about SIP botnets, how they are constructed and the threats they pose. >>> I would expect that probably 90% of us would choose the >>> botnet talk. (No disrespect intended to the spam-score folks, >>> just using an example.) The reality, though, is that the spam >>> score discussion might be far more useful in moving us toward >>> solutions that will help us with the people abusing SIP >>> systems today. I don't want to wake up some day and find out >>> that while we've been having a ton of discussions about >>> botnets, some idiot meanwhile is repeatedly connecting to my >>> SIP server and pumping our voicemail system full of SPIT. >>> >>> Maybe it's crazy on my part, but I want to see RUCUS have a >>> charter that results in an achievable plan and architecture. >>> >>> Yes, we should consider botnets as a potential source of SIP >>> spam and, yes, the potential existence of SIP botnets should >>> be included in our thinking about an architecture to address >>> SIP spam (so that any architecture we come up with does not >>> discount dealing with botnets). But I also think we need to >>> stay focused on what we can do now about the threats that are >>> out there today (before it's too late). Let's crawl first, >>> then walk, then run. >>> >>> My 2 cents, >>> Dan >>> >>> On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: >>> >>> Today, most of the spam email comes from bot-nets and recently >>> email spammers started to send massively from compromized >>> valid email accounts. I do not see why this would not become >>> also the biggest source of SIP spam in the future. >>> >>> Consequently, we should address this issue when developing an >>> architecture for reducing SIP spam in the RUCUS WG. The >>> architecture should be general enough for covering also means >>> that reduce SIP spam from bot nets and compromized accounts >>> >>> Whether or not to work on this problem is being discussed >>> highly controversially in the IETF. But considering that the >>> RUCUS BoF is targeted at establishing not a regular working >>> group, but an RFC 5111 Exploratory Group, I do not think it >>> would be appropriate to exclude such work from the beginning. >>> >>> It should rather be part of the exploratory work to find out >>> whether or not reducing SIP spam from bot nets is a target >>> worth to be attacked by the IETF. >>> >>> >>> -- >>> Dan York, CISSP, Director of Emerging Communication Technology >>> Office of the CTO Voxeo Corporation dyork@voxeo.com >>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>> >>> Bring your web applications to the phone. >>> Find out how at http://evolution.voxeo.com >>> >>> >>> >>> >>> >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> http://www.ietf.org/mailman/listinfo/rucus > > ------------------------------------------------------------------------ > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 03:44:17 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB56128C17D; Fri, 22 Feb 2008 03:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.086 X-Spam-Level: * X-Spam-Status: No, score=1.086 tagged_above=-999 required=5 tests=[AWL=-1.169, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_SPAM=2.3, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUbTo3d6ZwBf; Fri, 22 Feb 2008 03:44:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8E03A6B7A; Fri, 22 Feb 2008 03:44:16 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C473A6B7A for ; Fri, 22 Feb 2008 03:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af3KgweftARK for ; Fri, 22 Feb 2008 03:44:14 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B936F3A6839 for ; Fri, 22 Feb 2008 03:44:13 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 7CC582C000355; Fri, 22 Feb 2008 12:44:09 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrH9fE1mstx2; Fri, 22 Feb 2008 12:44:09 +0100 (CET) Received: by smtp0.neclab.eu (Postfix, from userid 1001) id 5DB7F2C009E8F; Fri, 22 Feb 2008 12:44:09 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id BF9172C000355; Fri, 22 Feb 2008 12:43:48 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 12:42:47 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office> In-Reply-To: <47BEAEE3.4040701@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] [Rucus] Botnets, take 2... Re: Draft RUCUS charter Thread-Index: Ach1RFsqW1IrRPPCSaa1Bsu1tWF7hgAAnyJg References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu> <47BEAEE3.4040701@gmx.net> From: "Jan Seedorf" To: , "Signaling TO Prevent SPIT" X-Sanitizer: This message has been sanitized! Cc: rucus@ietf.org, Juergen Quittek Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear Hannes, > I think we should put Henning's classification somewhere in > our documents. I also like Henning's classification because it narrows down where the problem with botnets regarding SPIT is. > > - Uses credentials, spams addresses in addressbook: > whitelists don't > > help, but at least the sender can be identified and > fixed/fined/taken > > offline. I fully agree: this is the problem and the "compromised identity" then needs to be identified and blocked. One question then is, how can we share the identification of a not-trustworthy identity (as perceived by end-users or domains) among SIP-entities/domains. One building block I see here clearly is http://www.ietf.org/internet-drafts/draft-niccolini-sipping-spam-feedback-00.txt for giving users the possibility to indicate that some identity may not be trustworthy anymore (e.g., because it got compromised in the sense Henning describes above). Additionally, http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 and http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam-score-semantics-00.txt offer a solution for signalling such information between entities. Note that in the semantics draft we tried to point the importance of having a precise meaning associated with a SPIT score. - Jan > -----Original Message----- > From: spitstop-bounces@listserv.netlab.nec.de > [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of > Hannes Tschofenig > Sent: Friday, February 22, 2008 12:16 PM > To: Signaling TO Prevent SPIT > Cc: Brian Azzopardi; rucus@ietf.org; Juergen Quittek > Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft > RUCUS charter > > I think we should put Henning's classification somewhere in > our documents. > > I had a chat with Peter Saint-Andre this week and he reported > me about problems they had with malicious users (potentially > using the XMPP servers for file sharing) in their XMPP server > infrastructure. He told me that their community is looking > into a mechanism to allow one domain to report problems to > another domain. This would correspond to Henning's 2nd > category below and a mechanisms similar to the one described > in > http://www.ietf.org/internet-drafts/draft-niccolini-sipping-sp > am-feedback-00.txt > would be useful (expect that it would not be run between the > end host and the VoIP provider but between two VoIP providers). > > Ciao > Hannes > > PS: I put Peter on CC in case I misunderstood something. > > Henning Schulzrinne wrote: > > There are three sub-cases of bot nets: > > > > - Just uses host, without credentials: identity-based whitelisting > > works (subject to the usual problems with whitelisting) > > > > - Uses credentials, but spews randomly: unlikely that the recipient > > will have that person in their whitelist, so still manageable. > > > > - Uses credentials, spams addresses in addressbook: > whitelists don't > > help, but at least the sender can be identified and > fixed/fined/taken > > offline. > > > > I'm not trying to downplay bot nets, just that this is a bit more > > nuanced. > > > > Henning > > > > On Feb 20, 2008, at 3:37 AM, Brian Azzopardi wrote: > > > > > >> Dan, > >> > >> I am afraid that we may have to hit the ground running. > Email spam is > >> already a big industry with well established operators. > Spewing out > >> SPIT instead of email spam is just another 'product' for them. > >> Only amateur SPITers will use spitter and other such tools - the > >> professional ones already have the infrastructure in place > and they'd > >> be irrational not to reuse it for SPIT - they will just short- > >> circuit to your step 5. We do need to think deeply about > botnets - > >> they are the principal means of sending spam and have been for at > >> least the last 2 years. > >> > >> Regards, > >> > >> Brian Azzopardi - Senior Business Analyst GFI Software - > www.gfi.com > >> > >> > >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On > >> Behalf Of Dan York > >> Sent: 19 February 2008 21:24 > >> To: Juergen Quittek > >> Cc: rucus@ietf.org; Signaling TO Prevent SPIT > >> Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter > >> > >> Juergen (and Saverio and others), > >> > >> I appreciate the point you are raising here. My interest and > >> passion are in networking, communication and security. To me, > >> botnets are both incredibly fascinating and incredibly > terrifying. > >> I agree with you that botnets very certainly may be the biggest > >> source of SIP spam in the future. > >> > >> Here's my problem: > >> > >> We have to crawl before we can walk and before we can run. > >> > >> Let's say that this is the (incredibly simplistic view of the) > >> evolution of email spam: > >> > >> 1. Someone figures out that they can send advertisements > to a range > >> of email addresses they have collected. > >> 2. Someone realizes that they can add those addresses to a > "mailing > >> list" to easily send to a large number of addresses. > >> 3. Tools are developed that automate the collection of > addresses and > >> the sending out of messages. > >> 4. At a certain time, there are enough people using email > out there > >> that this whole area of email advertising is a huge financial > >> marketplace. Companies/entities set up server farms to > just send out > >> tons of email messages. (Defenders blacklist those servers.) > >> 5. Those "servers" get distributed into massive botnets > and are then > >> able to avoid blacklisting, etc. > >> > >> I have absolutely no doubt that SIP spam will > unfortunately follow > >> the exact same trajectory. We're already seeing the tools to > >> automate SPIT (here's one: > http://www.hackingvoip.com/tools/spitter.tar.gz > >> ). At some point we will hit my #4 when there are enough people > >> using SIP *with publicly accessible SIP addresses* that it > becomes > >> financially lucrative enough for the larger automation to occur - > >> and following on the heels of that will be the botnets. It will > >> happen. To me it's not a question of IF but rather WHEN. > >> > >> Right now, though, we're still in my steps 1-3 as people start to > >> get SIP endpoints and realize how they can abuse them. > >> > >> My concern about adding the focus on botnets into RUCUS is > the fact > >> that we can easily get distracted into looking at how to solve > >> bigger issues and not get done the smaller issues that we can > >> perhaps address today. > >> > >> Let's face it, probably all of us on this list would be > categorized > >> as early adopters who like to explore cutting edge > technologies. We > >> like to chase bright shiny objects and what is new and sexy and > >> interesting. Let's say that you have a choice at the next > IETF to > >> listen to either: > >> 1. a presentation on a SIP header to pass a "spam score" value > >> between a SIP proxy and a UA; or > >> 2. a presentation about SIP botnets, how they are constructed and > >> the threats they pose. > >> I would expect that probably 90% of us would choose the > botnet talk. > >> (No disrespect intended to the spam-score folks, just using an > >> example.) The reality, though, is that the spam score discussion > >> might be far more useful in moving us toward solutions that will > >> help us with the people abusing SIP systems today. I > don't want to > >> wake up some day and find out that while we've been having > a ton of > >> discussions about botnets, some idiot meanwhile is repeatedly > >> connecting to my SIP server and pumping our voicemail > system full of > >> SPIT. > >> > >> Maybe it's crazy on my part, but I want to see RUCUS have > a charter > >> that results in an achievable plan and architecture. > >> > >> Yes, we should consider botnets as a potential source of SIP spam > >> and, yes, the potential existence of SIP botnets should be > included > >> in our thinking about an architecture to address SIP spam > (so that > >> any architecture we come up with does not discount dealing with > >> botnets). But I also think we need to stay focused on > what we can > >> do now about the threats that are out there today (before > it's too > >> late). Let's crawl first, then walk, then run. > >> > >> My 2 cents, > >> Dan > >> > >> On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: > >> Today, most of the spam email comes from bot-nets and recently > >> email spammers started to send massively from compromized > >> valid email accounts. I do not see why this would not become > >> also the biggest source of SIP spam in the future. > >> > >> Consequently, we should address this issue when developing an > >> architecture for reducing SIP spam in the RUCUS WG. The > >> architecture should be general enough for covering also means > >> that reduce SIP spam from bot nets and compromized accounts > >> > >> Whether or not to work on this problem is being discussed > >> highly controversially in the IETF. But considering that the > >> RUCUS BoF is targeted at establishing not a regular working > >> group, but an RFC 5111 Exploratory Group, I do not think it > >> would be appropriate to exclude such work from the beginning. > >> > >> It should rather be part of the exploratory work to find out > >> whether or not reducing SIP spam from bot nets is a target > >> worth to be attacked by the IETF. > >> > >> -- > >> Dan York, CISSP, Director of Emerging Communication Technology > >> Office of the CTO Voxeo Corporation dyork@voxeo.com > >> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > >> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > >> > >> Bring your web applications to the phone. > >> Find out how at http://evolution.voxeo.com > >> > >> > >> > >> > >> > >> > >> DISCLAIMER > >> The information contained in this electronic mail may be > >> confidential or legally privileged. It is for the intended > >> recipient(s) only. Should you receive this message in > error, please > >> notify the sender by replying to this mail. Unless > expressly stated, > >> opinions in this message are those of the individual > sender and not > >> of GFI. Unauthorized use of the contents is strictly prohibited. > >> While all care has been taken, GFI is not responsible for the > >> integrity of the contents of this electronic mail and any > >> attachments included within. > >> > >> This mail was checked for viruses by GFI MailSecurity. GFI also > >> develops anti-spam software (GFI MailEssentials), a fax > server (GFI > >> FAXmaker), and network security and management software (GFI > >> LANguard) - www.gfi.com > >> > >> _______________________________________________ > >> Rucus mailing list > >> Rucus@ietf.org > >> http://www.ietf.org/mailman/listinfo/rucus > >> > > > > _______________________________________________ > > spitstop mailing list > > spitstop@listserv.netlab.nec.de > > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > > > > _______________________________________________ > spitstop mailing list > spitstop@listserv.netlab.nec.de > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 03:51:04 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA13A3A6C5F; Fri, 22 Feb 2008 03:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.784 X-Spam-Level: X-Spam-Status: No, score=0.784 tagged_above=-999 required=5 tests=[AWL=-1.471, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_SPAM=2.3, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8g-8yazM6vK; Fri, 22 Feb 2008 03:51:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5489428C20F; Fri, 22 Feb 2008 03:51:03 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7523A6B7B for ; Fri, 22 Feb 2008 03:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfE+UdHv3WS4 for ; Fri, 22 Feb 2008 03:51:00 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 204023A6839 for ; Fri, 22 Feb 2008 03:50:59 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 11:50:54 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp049) with SMTP; 22 Feb 2008 12:50:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/75DBzFaj72KUF0wUasw2GHORQWzGScEnQGVJ3iI cNayj8x49axZCR Message-ID: <47BEB721.8040305@gmx.net> Date: Fri, 22 Feb 2008 13:50:57 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jan Seedorf References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu> <47BEAEE3.4040701@gmx.net> <113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org, Signaling TO Prevent SPIT , Juergen Quittek Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Jan, Jan Seedorf wrote: > Dear Hannes, > > >> I think we should put Henning's classification somewhere in >> our documents. >> > I also like Henning's classification because it narrows down where the problem with botnets regarding SPIT is. > > >>> - Uses credentials, spams addresses in addressbook: >>> >> whitelists don't >> >>> help, but at least the sender can be identified and >>> >> fixed/fined/taken >> >>> offline. >>> > I fully agree: this is the problem and the "compromised identity" then needs to be identified and blocked. One question then is, how can we share the identification of a not-trustworthy identity (as perceived by end-users or domains) among SIP-entities/domains. One building block I see here clearly is > http://www.ietf.org/internet-drafts/draft-niccolini-sipping-spam-feedback-00.txt > Let's take an example: When Henning's host is compromised and a bot is using Henning's account to send me spam then I would contact Henning (by using various ways) to tell him that something is wrong with his PC/phone/etc. I would not tell my VoIP provider that there is something wrong with Henning's account. Typically, this will lead to more problems rather than less -- such as no communication to Columbia University anymore because my VoIP provider just blocks all calls from that domain. (Just to reflect my experience with email problems in the company....) > for giving users the possibility to indicate that some identity may not be trustworthy anymore (e.g., because it got compromised in the sense Henning describes above). Additionally, > http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 > and > http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam-score-semantics-00.txt > offer a solution for signalling such information between entities. Note that in the semantics draft we tried to point the importance of having a precise meaning associated with a SPIT score. > I haven't read draft-seedorf-sipping-spam-score-semantics-00.txt yet. Comments later. Ciao Hannes > - Jan > > >> -----Original Message----- >> From: spitstop-bounces@listserv.netlab.nec.de >> [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of >> Hannes Tschofenig >> Sent: Friday, February 22, 2008 12:16 PM >> To: Signaling TO Prevent SPIT >> Cc: Brian Azzopardi; rucus@ietf.org; Juergen Quittek >> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft >> RUCUS charter >> >> I think we should put Henning's classification somewhere in >> our documents. >> >> I had a chat with Peter Saint-Andre this week and he reported >> me about problems they had with malicious users (potentially >> using the XMPP servers for file sharing) in their XMPP server >> infrastructure. He told me that their community is looking >> into a mechanism to allow one domain to report problems to >> another domain. This would correspond to Henning's 2nd >> category below and a mechanisms similar to the one described >> in >> http://www.ietf.org/internet-drafts/draft-niccolini-sipping-sp >> am-feedback-00.txt >> would be useful (expect that it would not be run between the >> end host and the VoIP provider but between two VoIP providers). >> >> Ciao >> Hannes >> >> PS: I put Peter on CC in case I misunderstood something. >> >> Henning Schulzrinne wrote: >> >>> There are three sub-cases of bot nets: >>> >>> - Just uses host, without credentials: identity-based whitelisting >>> works (subject to the usual problems with whitelisting) >>> >>> - Uses credentials, but spews randomly: unlikely that the recipient >>> will have that person in their whitelist, so still manageable. >>> >>> - Uses credentials, spams addresses in addressbook: >>> >> whitelists don't >> >>> help, but at least the sender can be identified and >>> >> fixed/fined/taken >> >>> offline. >>> >>> I'm not trying to downplay bot nets, just that this is a bit more >>> nuanced. >>> >>> Henning >>> >>> On Feb 20, 2008, at 3:37 AM, Brian Azzopardi wrote: >>> >>> >>> >>>> Dan, >>>> >>>> I am afraid that we may have to hit the ground running. >>>> >> Email spam is >> >>>> already a big industry with well established operators. >>>> >> Spewing out >> >>>> SPIT instead of email spam is just another 'product' for them. >>>> Only amateur SPITers will use spitter and other such tools - the >>>> professional ones already have the infrastructure in place >>>> >> and they'd >> >>>> be irrational not to reuse it for SPIT - they will just short- >>>> circuit to your step 5. We do need to think deeply about >>>> >> botnets - >> >>>> they are the principal means of sending spam and have been for at >>>> least the last 2 years. >>>> >>>> Regards, >>>> >>>> Brian Azzopardi - Senior Business Analyst GFI Software - >>>> >> www.gfi.com >> >>>> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On >>>> Behalf Of Dan York >>>> Sent: 19 February 2008 21:24 >>>> To: Juergen Quittek >>>> Cc: rucus@ietf.org; Signaling TO Prevent SPIT >>>> Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter >>>> >>>> Juergen (and Saverio and others), >>>> >>>> I appreciate the point you are raising here. My interest and >>>> passion are in networking, communication and security. To me, >>>> botnets are both incredibly fascinating and incredibly >>>> >> terrifying. >> >>>> I agree with you that botnets very certainly may be the biggest >>>> source of SIP spam in the future. >>>> >>>> Here's my problem: >>>> >>>> We have to crawl before we can walk and before we can run. >>>> >>>> Let's say that this is the (incredibly simplistic view of the) >>>> evolution of email spam: >>>> >>>> 1. Someone figures out that they can send advertisements >>>> >> to a range >> >>>> of email addresses they have collected. >>>> 2. Someone realizes that they can add those addresses to a >>>> >> "mailing >> >>>> list" to easily send to a large number of addresses. >>>> 3. Tools are developed that automate the collection of >>>> >> addresses and >> >>>> the sending out of messages. >>>> 4. At a certain time, there are enough people using email >>>> >> out there >> >>>> that this whole area of email advertising is a huge financial >>>> marketplace. Companies/entities set up server farms to >>>> >> just send out >> >>>> tons of email messages. (Defenders blacklist those servers.) >>>> 5. Those "servers" get distributed into massive botnets >>>> >> and are then >> >>>> able to avoid blacklisting, etc. >>>> >>>> I have absolutely no doubt that SIP spam will >>>> >> unfortunately follow >> >>>> the exact same trajectory. We're already seeing the tools to >>>> automate SPIT (here's one: >>>> >> http://www.hackingvoip.com/tools/spitter.tar.gz >> >>>> ). At some point we will hit my #4 when there are enough people >>>> using SIP *with publicly accessible SIP addresses* that it >>>> >> becomes >> >>>> financially lucrative enough for the larger automation to occur - >>>> and following on the heels of that will be the botnets. It will >>>> happen. To me it's not a question of IF but rather WHEN. >>>> >>>> Right now, though, we're still in my steps 1-3 as people start to >>>> get SIP endpoints and realize how they can abuse them. >>>> >>>> My concern about adding the focus on botnets into RUCUS is >>>> >> the fact >> >>>> that we can easily get distracted into looking at how to solve >>>> bigger issues and not get done the smaller issues that we can >>>> perhaps address today. >>>> >>>> Let's face it, probably all of us on this list would be >>>> >> categorized >> >>>> as early adopters who like to explore cutting edge >>>> >> technologies. We >> >>>> like to chase bright shiny objects and what is new and sexy and >>>> interesting. Let's say that you have a choice at the next >>>> >> IETF to >> >>>> listen to either: >>>> 1. a presentation on a SIP header to pass a "spam score" value >>>> between a SIP proxy and a UA; or >>>> 2. a presentation about SIP botnets, how they are constructed and >>>> the threats they pose. >>>> I would expect that probably 90% of us would choose the >>>> >> botnet talk. >> >>>> (No disrespect intended to the spam-score folks, just using an >>>> example.) The reality, though, is that the spam score discussion >>>> might be far more useful in moving us toward solutions that will >>>> help us with the people abusing SIP systems today. I >>>> >> don't want to >> >>>> wake up some day and find out that while we've been having >>>> >> a ton of >> >>>> discussions about botnets, some idiot meanwhile is repeatedly >>>> connecting to my SIP server and pumping our voicemail >>>> >> system full of >> >>>> SPIT. >>>> >>>> Maybe it's crazy on my part, but I want to see RUCUS have >>>> >> a charter >> >>>> that results in an achievable plan and architecture. >>>> >>>> Yes, we should consider botnets as a potential source of SIP spam >>>> and, yes, the potential existence of SIP botnets should be >>>> >> included >> >>>> in our thinking about an architecture to address SIP spam >>>> >> (so that >> >>>> any architecture we come up with does not discount dealing with >>>> botnets). But I also think we need to stay focused on >>>> >> what we can >> >>>> do now about the threats that are out there today (before >>>> >> it's too >> >>>> late). Let's crawl first, then walk, then run. >>>> >>>> My 2 cents, >>>> Dan >>>> >>>> On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: >>>> Today, most of the spam email comes from bot-nets and recently >>>> email spammers started to send massively from compromized >>>> valid email accounts. I do not see why this would not become >>>> also the biggest source of SIP spam in the future. >>>> >>>> Consequently, we should address this issue when developing an >>>> architecture for reducing SIP spam in the RUCUS WG. The >>>> architecture should be general enough for covering also means >>>> that reduce SIP spam from bot nets and compromized accounts >>>> >>>> Whether or not to work on this problem is being discussed >>>> highly controversially in the IETF. But considering that the >>>> RUCUS BoF is targeted at establishing not a regular working >>>> group, but an RFC 5111 Exploratory Group, I do not think it >>>> would be appropriate to exclude such work from the beginning. >>>> >>>> It should rather be part of the exploratory work to find out >>>> whether or not reducing SIP spam from bot nets is a target >>>> worth to be attacked by the IETF. >>>> >>>> -- >>>> Dan York, CISSP, Director of Emerging Communication Technology >>>> Office of the CTO Voxeo Corporation dyork@voxeo.com >>>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>>> >>>> Bring your web applications to the phone. >>>> Find out how at http://evolution.voxeo.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> DISCLAIMER >>>> The information contained in this electronic mail may be >>>> confidential or legally privileged. It is for the intended >>>> recipient(s) only. Should you receive this message in >>>> >> error, please >> >>>> notify the sender by replying to this mail. Unless >>>> >> expressly stated, >> >>>> opinions in this message are those of the individual >>>> >> sender and not >> >>>> of GFI. Unauthorized use of the contents is strictly prohibited. >>>> While all care has been taken, GFI is not responsible for the >>>> integrity of the contents of this electronic mail and any >>>> attachments included within. >>>> >>>> This mail was checked for viruses by GFI MailSecurity. GFI also >>>> develops anti-spam software (GFI MailEssentials), a fax >>>> >> server (GFI >> >>>> FAXmaker), and network security and management software (GFI >>>> LANguard) - www.gfi.com >>>> >>>> _______________________________________________ >>>> Rucus mailing list >>>> Rucus@ietf.org >>>> http://www.ietf.org/mailman/listinfo/rucus >>>> >>>> >>> _______________________________________________ >>> spitstop mailing list >>> spitstop@listserv.netlab.nec.de >>> https://listserv.netlab.nec.de/mailman/listinfo/spitstop >>> >>> >> _______________________________________________ >> spitstop mailing list >> spitstop@listserv.netlab.nec.de >> https://listserv.netlab.nec.de/mailman/listinfo/spitstop >> >> _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 04:04:21 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2B128C2A0; Fri, 22 Feb 2008 04:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[AWL=-1.821, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_SPAM=2.3, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm+ucdAz4ASG; Fri, 22 Feb 2008 04:04:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34CD728C17D; Fri, 22 Feb 2008 04:04:20 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96BD3A6C54 for ; Fri, 22 Feb 2008 04:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IymSYe8jxhl for ; Fri, 22 Feb 2008 04:04:17 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 3651128C17D for ; Fri, 22 Feb 2008 04:04:15 -0800 (PST) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id m1MC47e3008307; Fri, 22 Feb 2008 13:04:07 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id m1MC46PZ028892; Fri, 22 Feb 2008 13:04:06 +0100 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 13:04:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 13:03:53 +0100 Message-ID: <198A10EC585EC74687BCA414E2A5971802093DFC@MCHP7RDA.ww002.siemens.net> In-Reply-To: <47BEB721.8040305@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] [Rucus] Botnets, take 2... Re: Draft RUCUS charter Thread-Index: Ach1ST0pta8Oqt4YTyqRyqCVf1c5ZAAADsIQ References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu><47BEAEE3.4040701@gmx.net><113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office> <47BEB721.8040305@gmx.net> From: "Fischer, Kai" To: , "Signaling TO Prevent SPIT" , "Jan Seedorf" X-OriginalArrivalTime: 22 Feb 2008 12:04:06.0145 (UTC) FILETIME=[05DD5F10:01C8754B] Cc: rucus@ietf.org, Juergen Quittek Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > Let's take an example: > When Henning's host is compromised and a bot is using > Henning's account > to send me spam then I would contact Henning (by using > various ways) to > tell him that something is wrong with his PC/phone/etc. I > would not tell > my VoIP provider that there is something wrong with Henning's > account. > Typically, this will lead to more problems rather than less > -- such as > no communication to Columbia University anymore because my > VoIP provider > just blocks all calls from that domain. > > (Just to reflect my experience with email problems in the company....) I don't assume that the sender of spam usually is a person I personally know and whom I want to contact directly (still more personal disturbance and effort). Applying very restrictive white lists allowing only personal known people to contact me may be yes, but I expect that this is not usual scenario (I have no email white list). > -----Original Message----- > From: spitstop-bounces@listserv.netlab.nec.de > [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of > Hannes Tschofenig > Sent: Freitag, 22. Februar 2008 12:51 > To: Jan Seedorf > Cc: Brian Azzopardi; rucus@ietf.org; Signaling TO Prevent > SPIT; Juergen Quittek > Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft > RUCUS charter > > Hi Jan, > > > Jan Seedorf wrote: > > Dear Hannes, > > > > > >> I think we should put Henning's classification somewhere in > >> our documents. > >> > > I also like Henning's classification because it narrows > down where the problem with botnets regarding SPIT is. > > > > > >>> - Uses credentials, spams addresses in addressbook: > >>> > >> whitelists don't > >> > >>> help, but at least the sender can be identified and > >>> > >> fixed/fined/taken > >> > >>> offline. > >>> > > I fully agree: this is the problem and the "compromised > identity" then needs to be identified and blocked. One > question then is, how can we share the identification of a > not-trustworthy identity (as perceived by end-users or > domains) among SIP-entities/domains. One building block I see > here clearly is > > > http://www.ietf.org/internet-drafts/draft-niccolini-sipping-sp am-feedback-00.txt > > > > Let's take an example: > When Henning's host is compromised and a bot is using > Henning's account > to send me spam then I would contact Henning (by using > various ways) to > tell him that something is wrong with his PC/phone/etc. I > would not tell > my VoIP provider that there is something wrong with Henning's > account. > Typically, this will lead to more problems rather than less > -- such as > no communication to Columbia University anymore because my > VoIP provider > just blocks all calls from that domain. > > (Just to reflect my experience with email problems in the company....) > > > for giving users the possibility to indicate that some > identity may not be trustworthy anymore (e.g., because it got > compromised in the sense Henning describes above). Additionally, > > http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 > > and > > > http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam -score-semantics-00.txt > > offer a solution for signalling such information between > entities. Note that in the semantics draft we tried to point > the importance of having a precise meaning associated with a > SPIT score. > > > > I haven't read draft-seedorf-sipping-spam-score-semantics-00.txt yet. > Comments later. > > > Ciao > Hannes > > > - Jan > > > > > >> -----Original Message----- > >> From: spitstop-bounces@listserv.netlab.nec.de > >> [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of > >> Hannes Tschofenig > >> Sent: Friday, February 22, 2008 12:16 PM > >> To: Signaling TO Prevent SPIT > >> Cc: Brian Azzopardi; rucus@ietf.org; Juergen Quittek > >> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft > >> RUCUS charter > >> > >> I think we should put Henning's classification somewhere in > >> our documents. > >> > >> I had a chat with Peter Saint-Andre this week and he reported > >> me about problems they had with malicious users (potentially > >> using the XMPP servers for file sharing) in their XMPP server > >> infrastructure. He told me that their community is looking > >> into a mechanism to allow one domain to report problems to > >> another domain. This would correspond to Henning's 2nd > >> category below and a mechanisms similar to the one described > >> in > >> http://www.ietf.org/internet-drafts/draft-niccolini-sipping-sp > >> am-feedback-00.txt > >> would be useful (expect that it would not be run between the > >> end host and the VoIP provider but between two VoIP providers). > >> > >> Ciao > >> Hannes > >> > >> PS: I put Peter on CC in case I misunderstood something. > >> > >> Henning Schulzrinne wrote: > >> > >>> There are three sub-cases of bot nets: > >>> > >>> - Just uses host, without credentials: identity-based > whitelisting > >>> works (subject to the usual problems with whitelisting) > >>> > >>> - Uses credentials, but spews randomly: unlikely that the > recipient > >>> will have that person in their whitelist, so still manageable. > >>> > >>> - Uses credentials, spams addresses in addressbook: > >>> > >> whitelists don't > >> > >>> help, but at least the sender can be identified and > >>> > >> fixed/fined/taken > >> > >>> offline. > >>> > >>> I'm not trying to downplay bot nets, just that this is a bit more > >>> nuanced. > >>> > >>> Henning > >>> > >>> On Feb 20, 2008, at 3:37 AM, Brian Azzopardi wrote: > >>> > >>> > >>> > >>>> Dan, > >>>> > >>>> I am afraid that we may have to hit the ground running. > >>>> > >> Email spam is > >> > >>>> already a big industry with well established operators. > >>>> > >> Spewing out > >> > >>>> SPIT instead of email spam is just another 'product' for them. > >>>> Only amateur SPITers will use spitter and other such tools - the > >>>> professional ones already have the infrastructure in place > >>>> > >> and they'd > >> > >>>> be irrational not to reuse it for SPIT - they will just short- > >>>> circuit to your step 5. We do need to think deeply about > >>>> > >> botnets - > >> > >>>> they are the principal means of sending spam and have > been for at > >>>> least the last 2 years. > >>>> > >>>> Regards, > >>>> > >>>> Brian Azzopardi - Senior Business Analyst GFI Software - > >>>> > >> www.gfi.com > >> > >>>> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On > >>>> Behalf Of Dan York > >>>> Sent: 19 February 2008 21:24 > >>>> To: Juergen Quittek > >>>> Cc: rucus@ietf.org; Signaling TO Prevent SPIT > >>>> Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter > >>>> > >>>> Juergen (and Saverio and others), > >>>> > >>>> I appreciate the point you are raising here. My interest and > >>>> passion are in networking, communication and security. To me, > >>>> botnets are both incredibly fascinating and incredibly > >>>> > >> terrifying. > >> > >>>> I agree with you that botnets very certainly may be the biggest > >>>> source of SIP spam in the future. > >>>> > >>>> Here's my problem: > >>>> > >>>> We have to crawl before we can walk and before we can run. > >>>> > >>>> Let's say that this is the (incredibly simplistic view of the) > >>>> evolution of email spam: > >>>> > >>>> 1. Someone figures out that they can send advertisements > >>>> > >> to a range > >> > >>>> of email addresses they have collected. > >>>> 2. Someone realizes that they can add those addresses to a > >>>> > >> "mailing > >> > >>>> list" to easily send to a large number of addresses. > >>>> 3. Tools are developed that automate the collection of > >>>> > >> addresses and > >> > >>>> the sending out of messages. > >>>> 4. At a certain time, there are enough people using email > >>>> > >> out there > >> > >>>> that this whole area of email advertising is a huge financial > >>>> marketplace. Companies/entities set up server farms to > >>>> > >> just send out > >> > >>>> tons of email messages. (Defenders blacklist those servers.) > >>>> 5. Those "servers" get distributed into massive botnets > >>>> > >> and are then > >> > >>>> able to avoid blacklisting, etc. > >>>> > >>>> I have absolutely no doubt that SIP spam will > >>>> > >> unfortunately follow > >> > >>>> the exact same trajectory. We're already seeing the tools to > >>>> automate SPIT (here's one: > >>>> > >> http://www.hackingvoip.com/tools/spitter.tar.gz > >> > >>>> ). At some point we will hit my #4 when there are > enough people > >>>> using SIP *with publicly accessible SIP addresses* that it > >>>> > >> becomes > >> > >>>> financially lucrative enough for the larger automation > to occur - > >>>> and following on the heels of that will be the botnets. > It will > >>>> happen. To me it's not a question of IF but rather WHEN. > >>>> > >>>> Right now, though, we're still in my steps 1-3 as people > start to > >>>> get SIP endpoints and realize how they can abuse them. > >>>> > >>>> My concern about adding the focus on botnets into RUCUS is > >>>> > >> the fact > >> > >>>> that we can easily get distracted into looking at how to solve > >>>> bigger issues and not get done the smaller issues that we can > >>>> perhaps address today. > >>>> > >>>> Let's face it, probably all of us on this list would be > >>>> > >> categorized > >> > >>>> as early adopters who like to explore cutting edge > >>>> > >> technologies. We > >> > >>>> like to chase bright shiny objects and what is new and sexy and > >>>> interesting. Let's say that you have a choice at the next > >>>> > >> IETF to > >> > >>>> listen to either: > >>>> 1. a presentation on a SIP header to pass a "spam score" value > >>>> between a SIP proxy and a UA; or > >>>> 2. a presentation about SIP botnets, how they are > constructed and > >>>> the threats they pose. > >>>> I would expect that probably 90% of us would choose the > >>>> > >> botnet talk. > >> > >>>> (No disrespect intended to the spam-score folks, just using an > >>>> example.) The reality, though, is that the spam score > discussion > >>>> might be far more useful in moving us toward solutions > that will > >>>> help us with the people abusing SIP systems today. I > >>>> > >> don't want to > >> > >>>> wake up some day and find out that while we've been having > >>>> > >> a ton of > >> > >>>> discussions about botnets, some idiot meanwhile is repeatedly > >>>> connecting to my SIP server and pumping our voicemail > >>>> > >> system full of > >> > >>>> SPIT. > >>>> > >>>> Maybe it's crazy on my part, but I want to see RUCUS have > >>>> > >> a charter > >> > >>>> that results in an achievable plan and architecture. > >>>> > >>>> Yes, we should consider botnets as a potential source of > SIP spam > >>>> and, yes, the potential existence of SIP botnets should be > >>>> > >> included > >> > >>>> in our thinking about an architecture to address SIP spam > >>>> > >> (so that > >> > >>>> any architecture we come up with does not discount dealing with > >>>> botnets). But I also think we need to stay focused on > >>>> > >> what we can > >> > >>>> do now about the threats that are out there today (before > >>>> > >> it's too > >> > >>>> late). Let's crawl first, then walk, then run. > >>>> > >>>> My 2 cents, > >>>> Dan > >>>> > >>>> On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: > >>>> Today, most of the spam email comes from bot-nets and recently > >>>> email spammers started to send massively from compromized > >>>> valid email accounts. I do not see why this would not become > >>>> also the biggest source of SIP spam in the future. > >>>> > >>>> Consequently, we should address this issue when developing an > >>>> architecture for reducing SIP spam in the RUCUS WG. The > >>>> architecture should be general enough for covering also means > >>>> that reduce SIP spam from bot nets and compromized accounts > >>>> > >>>> Whether or not to work on this problem is being discussed > >>>> highly controversially in the IETF. But considering that the > >>>> RUCUS BoF is targeted at establishing not a regular working > >>>> group, but an RFC 5111 Exploratory Group, I do not think it > >>>> would be appropriate to exclude such work from the beginning. > >>>> > >>>> It should rather be part of the exploratory work to find out > >>>> whether or not reducing SIP spam from bot nets is a target > >>>> worth to be attacked by the IETF. > >>>> > >>>> -- > >>>> Dan York, CISSP, Director of Emerging Communication Technology > >>>> Office of the CTO Voxeo Corporation dyork@voxeo.com > >>>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > >>>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > >>>> > >>>> Bring your web applications to the phone. > >>>> Find out how at http://evolution.voxeo.com > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> DISCLAIMER > >>>> The information contained in this electronic mail may be > >>>> confidential or legally privileged. It is for the intended > >>>> recipient(s) only. Should you receive this message in > >>>> > >> error, please > >> > >>>> notify the sender by replying to this mail. Unless > >>>> > >> expressly stated, > >> > >>>> opinions in this message are those of the individual > >>>> > >> sender and not > >> > >>>> of GFI. Unauthorized use of the contents is strictly > prohibited. > >>>> While all care has been taken, GFI is not responsible for the > >>>> integrity of the contents of this electronic mail and any > >>>> attachments included within. > >>>> > >>>> This mail was checked for viruses by GFI MailSecurity. GFI also > >>>> develops anti-spam software (GFI MailEssentials), a fax > >>>> > >> server (GFI > >> > >>>> FAXmaker), and network security and management software (GFI > >>>> LANguard) - www.gfi.com > >>>> > >>>> _______________________________________________ > >>>> Rucus mailing list > >>>> Rucus@ietf.org > >>>> http://www.ietf.org/mailman/listinfo/rucus > >>>> > >>>> > >>> _______________________________________________ > >>> spitstop mailing list > >>> spitstop@listserv.netlab.nec.de > >>> https://listserv.netlab.nec.de/mailman/listinfo/spitstop > >>> > >>> > >> _______________________________________________ > >> spitstop mailing list > >> spitstop@listserv.netlab.nec.de > >> https://listserv.netlab.nec.de/mailman/listinfo/spitstop > >> > >> > > _______________________________________________ > spitstop mailing list > spitstop@listserv.netlab.nec.de > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 04:07:47 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A5428C2F8; Fri, 22 Feb 2008 04:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.628 X-Spam-Level: X-Spam-Status: No, score=0.628 tagged_above=-999 required=5 tests=[AWL=-1.235, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_SPAM=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egOTkXWkwEva; Fri, 22 Feb 2008 04:07:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0CC28C298; Fri, 22 Feb 2008 04:07:46 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A520028C2F4 for ; Fri, 22 Feb 2008 04:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cE4+QpGMQK8I for ; Fri, 22 Feb 2008 04:07:44 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 9BC0028C29E for ; Fri, 22 Feb 2008 04:07:44 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6AE922C000355; Fri, 22 Feb 2008 13:07:40 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qkw5rHQIsZg; Fri, 22 Feb 2008 13:07:40 +0100 (CET) Received: by smtp0.neclab.eu (Postfix, from userid 1001) id 59FA42C000357; Fri, 22 Feb 2008 13:07:40 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 1CC5D2C000355; Fri, 22 Feb 2008 13:07:30 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 13:07:29 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DB88@mx1.office> In-Reply-To: <47BEAEE3.4040701@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] [Rucus] Botnets, take 2... Re: Draft RUCUS charter Thread-Index: Ach1RFs2RyYlR9YvTIKsWmpxvr2fTwAA9quw References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu> <47BEAEE3.4040701@gmx.net> From: "Saverio Niccolini" To: , "Signaling TO Prevent SPIT" X-Sanitizer: This message has been sanitized! Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes, all, > I had a chat with Peter Saint-Andre this week and he reported > me about problems they had with malicious users (potentially > using the XMPP servers for file sharing) in their XMPP server > infrastructure. He told me that their community is looking > into a mechanism to allow one domain to report problems to > another domain. This would correspond to Henning's 2nd > category below and a mechanisms similar to the one described > in > http://www.ietf.org/internet-drafts/draft-niccolini-sipping-sp am-feedback-00.txt > would be useful (expect that it would not be run between the > end host and the VoIP provider but between two VoIP providers). Right, actually this is why we inserted this potential communication interface in the SPITSTOP draft, see interface "b" among providers in: http://tools.ietf.org/html/draft-niccolini-sipping-spitstop-01#page-6 Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 04:19:37 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DAE928C2C8; Fri, 22 Feb 2008 04:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR7agiWaJunl; Fri, 22 Feb 2008 04:19:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA74128C2AF; Fri, 22 Feb 2008 04:19:33 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D5C28C1D9 for ; Fri, 22 Feb 2008 04:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 382IQfyzfJkF for ; Fri, 22 Feb 2008 04:19:31 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5569428C218 for ; Fri, 22 Feb 2008 04:19:31 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 149472C000355; Fri, 22 Feb 2008 13:19:27 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRht3UkMfIWJ; Fri, 22 Feb 2008 13:19:27 +0100 (CET) Received: by smtp0.neclab.eu (Postfix, from userid 1001) id 002022C000357; Fri, 22 Feb 2008 13:19:26 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id ADB8C2C000355; Fri, 22 Feb 2008 13:19:16 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 22 Feb 2008 13:19:15 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DB8D@mx1.office> In-Reply-To: <47BEB721.8040305@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] [Rucus] Botnets, take 2... Re: Draft RUCUS charter Thread-Index: Ach1SUC506mzvPJHRR6IMElR1Qc4AgAAkkGg References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> DEFANGED[4]:<42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu><47BEAEE3.4040701@gmx.net><113091BD57179D4491C19DA7E10CD69601B5639F@mx1.offi " " ce> <47BEB721.8040305@gmx.net> From: "Saverio Niccolini" To: , "Signaling TO Prevent SPIT" X-Sanitizer: This message has been sanitized! MIME-Version: 1.0 Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes, all, > Let's take an example: > When Henning's host is compromised and a bot is using > Henning's account to send me spam then I would contact > Henning (by using various ways) to tell him that something is > wrong with his PC/phone/etc. I would not tell my VoIP > provider that there is something wrong with Henning's account. > Typically, this will lead to more problems rather than less > -- such as no communication to Columbia University anymore > because my VoIP provider just blocks all calls from that domain. > > (Just to reflect my experience with email problems in the company....) You do not contact Henning directly to tell him that something is wrong. You have to rely on your infrastructure to take the necessary countermeasures otherwise it is the anarchy... That is why exchanging reputation of identities (as perceived by end-users or domains) is an important building block. Such reputation system (one of the points of RFC 5039) can be built using mechanisms like feedbacks: http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 and spam scores: http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 of course there are privacy issues that apply (but this is a problem of reputation systems as well) :-) It seems this list is converging to the point we tried to raise since 2006, I should be happy :-) Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 04:29:47 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BCB728C340; Fri, 22 Feb 2008 04:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CoIv95fAWW3; Fri, 22 Feb 2008 04:29:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C539328C2FF; Fri, 22 Feb 2008 04:29:45 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE4828C315 for ; Fri, 22 Feb 2008 04:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UfUq18PJjFV for ; Fri, 22 Feb 2008 04:29:43 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3CFE928C2FF for ; Fri, 22 Feb 2008 04:29:42 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 12:29:37 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp046) with SMTP; 22 Feb 2008 13:29:37 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/z4cYahAbzzeRkY/QSn7tVPTJHRQ9MsDdYAXyP0U u+MrknHLojEOEw Message-ID: <47BEC03A.8070009@gmx.net> Date: Fri, 22 Feb 2008 14:29:46 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Fischer, Kai" References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu><47BEAEE3.4040701@gmx.net><113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office> <47BEB721.8040305@gmx.net> <198A10EC585EC74687BCA414E2A5971802093DFC@MCHP7RDA.ww002.siemens.net> In-Reply-To: <198A10EC585EC74687BCA414E2A5971802093DFC@MCHP7RDA.ww002.siemens.net> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org, Jan Seedorf , Juergen Quittek Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Kai, Fischer, Kai wrote: >> Let's take an example: >> When Henning's host is compromised and a bot is using >> Henning's account >> to send me spam then I would contact Henning (by using >> various ways) to >> tell him that something is wrong with his PC/phone/etc. I >> would not tell >> my VoIP provider that there is something wrong with Henning's >> account. >> Typically, this will lead to more problems rather than less >> -- such as >> no communication to Columbia University anymore because my >> VoIP provider >> just blocks all calls from that domain. >> >> (Just to reflect my experience with email problems in the company....) >> > > I don't assume that the sender of spam usually is a person I personally > know and whom I want to contact directly (still more personal > disturbance and effort). Applying very restrictive white lists allowing > only personal known people to contact me may be yes, but I expect that > this is not usual scenario (I have no email white list). > > The spammer is not known; however, for the case we are considering here the account of someone from your buddy list is being used for spamming. If you are spamming me then I would obviously get in touch with you and ask you what you want. It is true that you have no email white list -- this is, however, a drawback for email that we don't need to repeat again. Consider Instant Messaging, for example, many people us a mixture between white lists and black lists. Very common today! For the PSTN there are obviously no white lists either Ciao Hannes > >> -----Original Message----- >> From: spitstop-bounces@listserv.netlab.nec.de >> [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of >> Hannes Tschofenig >> Sent: Freitag, 22. Februar 2008 12:51 >> To: Jan Seedorf >> Cc: Brian Azzopardi; rucus@ietf.org; Signaling TO Prevent >> SPIT; Juergen Quittek >> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft >> RUCUS charter >> >> Hi Jan, >> >> >> Jan Seedorf wrote: >> >>> Dear Hannes, >>> >>> >>> >>>> I think we should put Henning's classification somewhere in >>>> our documents. >>>> >>>> >>> I also like Henning's classification because it narrows >>> >> down where the problem with botnets regarding SPIT is. >> >>> >>> >>>>> - Uses credentials, spams addresses in addressbook: >>>>> >>>>> >>>> whitelists don't >>>> >>>> >>>>> help, but at least the sender can be identified and >>>>> >>>>> >>>> fixed/fined/taken >>>> >>>> >>>>> offline. >>>>> >>>>> >>> I fully agree: this is the problem and the "compromised >>> >> identity" then needs to be identified and blocked. One >> question then is, how can we share the identification of a >> not-trustworthy identity (as perceived by end-users or >> domains) among SIP-entities/domains. One building block I see >> here clearly is >> >> http://www.ietf.org/internet-drafts/draft-niccolini-sipping-sp >> > am-feedback-00.txt > >>> >>> >> Let's take an example: >> When Henning's host is compromised and a bot is using >> Henning's account >> to send me spam then I would contact Henning (by using >> various ways) to >> tell him that something is wrong with his PC/phone/etc. I >> would not tell >> my VoIP provider that there is something wrong with Henning's >> account. >> Typically, this will lead to more problems rather than less >> -- such as >> no communication to Columbia University anymore because my >> VoIP provider >> just blocks all calls from that domain. >> >> (Just to reflect my experience with email problems in the company....) >> >> >>> for giving users the possibility to indicate that some >>> >> identity may not be trustworthy anymore (e.g., because it got >> compromised in the sense Henning describes above). Additionally, >> >>> http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 >>> and >>> >>> >> http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam >> > -score-semantics-00.txt > >>> offer a solution for signalling such information between >>> >> entities. Note that in the semantics draft we tried to point >> the importance of having a precise meaning associated with a >> SPIT score. >> >>> >>> >> I haven't read draft-seedorf-sipping-spam-score-semantics-00.txt yet. >> Comments later. >> >> >> Ciao >> Hannes >> >> >>> - Jan >>> >>> >>> >>>> -----Original Message----- >>>> From: spitstop-bounces@listserv.netlab.nec.de >>>> [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf Of >>>> Hannes Tschofenig >>>> Sent: Friday, February 22, 2008 12:16 PM >>>> To: Signaling TO Prevent SPIT >>>> Cc: Brian Azzopardi; rucus@ietf.org; Juergen Quittek >>>> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft >>>> RUCUS charter >>>> >>>> I think we should put Henning's classification somewhere in >>>> our documents. >>>> >>>> I had a chat with Peter Saint-Andre this week and he reported >>>> me about problems they had with malicious users (potentially >>>> using the XMPP servers for file sharing) in their XMPP server >>>> infrastructure. He told me that their community is looking >>>> into a mechanism to allow one domain to report problems to >>>> another domain. This would correspond to Henning's 2nd >>>> category below and a mechanisms similar to the one described >>>> in >>>> http://www.ietf.org/internet-drafts/draft-niccolini-sipping-sp >>>> am-feedback-00.txt >>>> would be useful (expect that it would not be run between the >>>> end host and the VoIP provider but between two VoIP providers). >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: I put Peter on CC in case I misunderstood something. >>>> >>>> Henning Schulzrinne wrote: >>>> >>>> >>>>> There are three sub-cases of bot nets: >>>>> >>>>> - Just uses host, without credentials: identity-based >>>>> >> whitelisting >> >>>>> works (subject to the usual problems with whitelisting) >>>>> >>>>> - Uses credentials, but spews randomly: unlikely that the >>>>> >> recipient >> >>>>> will have that person in their whitelist, so still manageable. >>>>> >>>>> - Uses credentials, spams addresses in addressbook: >>>>> >>>>> >>>> whitelists don't >>>> >>>> >>>>> help, but at least the sender can be identified and >>>>> >>>>> >>>> fixed/fined/taken >>>> >>>> >>>>> offline. >>>>> >>>>> I'm not trying to downplay bot nets, just that this is a bit more >>>>> nuanced. >>>>> >>>>> Henning >>>>> >>>>> On Feb 20, 2008, at 3:37 AM, Brian Azzopardi wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Dan, >>>>>> >>>>>> I am afraid that we may have to hit the ground running. >>>>>> >>>>>> >>>> Email spam is >>>> >>>> >>>>>> already a big industry with well established operators. >>>>>> >>>>>> >>>> Spewing out >>>> >>>> >>>>>> SPIT instead of email spam is just another 'product' for them. >>>>>> Only amateur SPITers will use spitter and other such tools - the >>>>>> professional ones already have the infrastructure in place >>>>>> >>>>>> >>>> and they'd >>>> >>>> >>>>>> be irrational not to reuse it for SPIT - they will just short- >>>>>> circuit to your step 5. We do need to think deeply about >>>>>> >>>>>> >>>> botnets - >>>> >>>> >>>>>> they are the principal means of sending spam and have >>>>>> >> been for at >> >>>>>> least the last 2 years. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Brian Azzopardi - Senior Business Analyst GFI Software - >>>>>> >>>>>> >>>> www.gfi.com >>>> >>>> >>>>>> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On >>>>>> Behalf Of Dan York >>>>>> Sent: 19 February 2008 21:24 >>>>>> To: Juergen Quittek >>>>>> Cc: rucus@ietf.org; Signaling TO Prevent SPIT >>>>>> Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter >>>>>> >>>>>> Juergen (and Saverio and others), >>>>>> >>>>>> I appreciate the point you are raising here. My interest and >>>>>> passion are in networking, communication and security. To me, >>>>>> botnets are both incredibly fascinating and incredibly >>>>>> >>>>>> >>>> terrifying. >>>> >>>> >>>>>> I agree with you that botnets very certainly may be the biggest >>>>>> source of SIP spam in the future. >>>>>> >>>>>> Here's my problem: >>>>>> >>>>>> We have to crawl before we can walk and before we can run. >>>>>> >>>>>> Let's say that this is the (incredibly simplistic view of the) >>>>>> evolution of email spam: >>>>>> >>>>>> 1. Someone figures out that they can send advertisements >>>>>> >>>>>> >>>> to a range >>>> >>>> >>>>>> of email addresses they have collected. >>>>>> 2. Someone realizes that they can add those addresses to a >>>>>> >>>>>> >>>> "mailing >>>> >>>> >>>>>> list" to easily send to a large number of addresses. >>>>>> 3. Tools are developed that automate the collection of >>>>>> >>>>>> >>>> addresses and >>>> >>>> >>>>>> the sending out of messages. >>>>>> 4. At a certain time, there are enough people using email >>>>>> >>>>>> >>>> out there >>>> >>>> >>>>>> that this whole area of email advertising is a huge financial >>>>>> marketplace. Companies/entities set up server farms to >>>>>> >>>>>> >>>> just send out >>>> >>>> >>>>>> tons of email messages. (Defenders blacklist those servers.) >>>>>> 5. Those "servers" get distributed into massive botnets >>>>>> >>>>>> >>>> and are then >>>> >>>> >>>>>> able to avoid blacklisting, etc. >>>>>> >>>>>> I have absolutely no doubt that SIP spam will >>>>>> >>>>>> >>>> unfortunately follow >>>> >>>> >>>>>> the exact same trajectory. We're already seeing the tools to >>>>>> automate SPIT (here's one: >>>>>> >>>>>> >>>> http://www.hackingvoip.com/tools/spitter.tar.gz >>>> >>>> >>>>>> ). At some point we will hit my #4 when there are >>>>>> >> enough people >> >>>>>> using SIP *with publicly accessible SIP addresses* that it >>>>>> >>>>>> >>>> becomes >>>> >>>> >>>>>> financially lucrative enough for the larger automation >>>>>> >> to occur - >> >>>>>> and following on the heels of that will be the botnets. >>>>>> >> It will >> >>>>>> happen. To me it's not a question of IF but rather WHEN. >>>>>> >>>>>> Right now, though, we're still in my steps 1-3 as people >>>>>> >> start to >> >>>>>> get SIP endpoints and realize how they can abuse them. >>>>>> >>>>>> My concern about adding the focus on botnets into RUCUS is >>>>>> >>>>>> >>>> the fact >>>> >>>> >>>>>> that we can easily get distracted into looking at how to solve >>>>>> bigger issues and not get done the smaller issues that we can >>>>>> perhaps address today. >>>>>> >>>>>> Let's face it, probably all of us on this list would be >>>>>> >>>>>> >>>> categorized >>>> >>>> >>>>>> as early adopters who like to explore cutting edge >>>>>> >>>>>> >>>> technologies. We >>>> >>>> >>>>>> like to chase bright shiny objects and what is new and sexy and >>>>>> interesting. Let's say that you have a choice at the next >>>>>> >>>>>> >>>> IETF to >>>> >>>> >>>>>> listen to either: >>>>>> 1. a presentation on a SIP header to pass a "spam score" value >>>>>> between a SIP proxy and a UA; or >>>>>> 2. a presentation about SIP botnets, how they are >>>>>> >> constructed and >> >>>>>> the threats they pose. >>>>>> I would expect that probably 90% of us would choose the >>>>>> >>>>>> >>>> botnet talk. >>>> >>>> >>>>>> (No disrespect intended to the spam-score folks, just using an >>>>>> example.) The reality, though, is that the spam score >>>>>> >> discussion >> >>>>>> might be far more useful in moving us toward solutions >>>>>> >> that will >> >>>>>> help us with the people abusing SIP systems today. I >>>>>> >>>>>> >>>> don't want to >>>> >>>> >>>>>> wake up some day and find out that while we've been having >>>>>> >>>>>> >>>> a ton of >>>> >>>> >>>>>> discussions about botnets, some idiot meanwhile is repeatedly >>>>>> connecting to my SIP server and pumping our voicemail >>>>>> >>>>>> >>>> system full of >>>> >>>> >>>>>> SPIT. >>>>>> >>>>>> Maybe it's crazy on my part, but I want to see RUCUS have >>>>>> >>>>>> >>>> a charter >>>> >>>> >>>>>> that results in an achievable plan and architecture. >>>>>> >>>>>> Yes, we should consider botnets as a potential source of >>>>>> >> SIP spam >> >>>>>> and, yes, the potential existence of SIP botnets should be >>>>>> >>>>>> >>>> included >>>> >>>> >>>>>> in our thinking about an architecture to address SIP spam >>>>>> >>>>>> >>>> (so that >>>> >>>> >>>>>> any architecture we come up with does not discount dealing with >>>>>> botnets). But I also think we need to stay focused on >>>>>> >>>>>> >>>> what we can >>>> >>>> >>>>>> do now about the threats that are out there today (before >>>>>> >>>>>> >>>> it's too >>>> >>>> >>>>>> late). Let's crawl first, then walk, then run. >>>>>> >>>>>> My 2 cents, >>>>>> Dan >>>>>> >>>>>> On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: >>>>>> Today, most of the spam email comes from bot-nets and recently >>>>>> email spammers started to send massively from compromized >>>>>> valid email accounts. I do not see why this would not become >>>>>> also the biggest source of SIP spam in the future. >>>>>> >>>>>> Consequently, we should address this issue when developing an >>>>>> architecture for reducing SIP spam in the RUCUS WG. The >>>>>> architecture should be general enough for covering also means >>>>>> that reduce SIP spam from bot nets and compromized accounts >>>>>> >>>>>> Whether or not to work on this problem is being discussed >>>>>> highly controversially in the IETF. But considering that the >>>>>> RUCUS BoF is targeted at establishing not a regular working >>>>>> group, but an RFC 5111 Exploratory Group, I do not think it >>>>>> would be appropriate to exclude such work from the beginning. >>>>>> >>>>>> It should rather be part of the exploratory work to find out >>>>>> whether or not reducing SIP spam from bot nets is a target >>>>>> worth to be attacked by the IETF. >>>>>> >>>>>> -- >>>>>> Dan York, CISSP, Director of Emerging Communication Technology >>>>>> Office of the CTO Voxeo Corporation dyork@voxeo.com >>>>>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>>>>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>>>>> >>>>>> Bring your web applications to the phone. >>>>>> Find out how at http://evolution.voxeo.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> DISCLAIMER >>>>>> The information contained in this electronic mail may be >>>>>> confidential or legally privileged. It is for the intended >>>>>> recipient(s) only. Should you receive this message in >>>>>> >>>>>> >>>> error, please >>>> >>>> >>>>>> notify the sender by replying to this mail. Unless >>>>>> >>>>>> >>>> expressly stated, >>>> >>>> >>>>>> opinions in this message are those of the individual >>>>>> >>>>>> >>>> sender and not >>>> >>>> >>>>>> of GFI. Unauthorized use of the contents is strictly >>>>>> >> prohibited. >> >>>>>> While all care has been taken, GFI is not responsible for the >>>>>> integrity of the contents of this electronic mail and any >>>>>> attachments included within. >>>>>> >>>>>> This mail was checked for viruses by GFI MailSecurity. GFI also >>>>>> develops anti-spam software (GFI MailEssentials), a fax >>>>>> >>>>>> >>>> server (GFI >>>> >>>> >>>>>> FAXmaker), and network security and management software (GFI >>>>>> LANguard) - www.gfi.com >>>>>> >>>>>> _______________________________________________ >>>>>> Rucus mailing list >>>>>> Rucus@ietf.org >>>>>> http://www.ietf.org/mailman/listinfo/rucus >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> spitstop mailing list >>>>> spitstop@listserv.netlab.nec.de >>>>> https://listserv.netlab.nec.de/mailman/listinfo/spitstop >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> spitstop mailing list >>>> spitstop@listserv.netlab.nec.de >>>> https://listserv.netlab.nec.de/mailman/listinfo/spitstop >>>> >>>> >>>> >> _______________________________________________ >> spitstop mailing list >> spitstop@listserv.netlab.nec.de >> https://listserv.netlab.nec.de/mailman/listinfo/spitstop >> >> _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 04:30:06 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE5828C34E; Fri, 22 Feb 2008 04:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.356 X-Spam-Level: X-Spam-Status: No, score=-0.356 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRe-TpSwGYmi; Fri, 22 Feb 2008 04:30:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F192328C340; Fri, 22 Feb 2008 04:30:04 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148CD28C340 for ; Fri, 22 Feb 2008 04:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJZMrBgh72Vd for ; Fri, 22 Feb 2008 04:30:01 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7FBAC28C315 for ; Fri, 22 Feb 2008 04:30:00 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 12:29:55 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp036) with SMTP; 22 Feb 2008 13:29:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/KnuQZPkvK1lJeXGYC7nK+ioDDOO/T9ucM11/Y07 4200lOSxiwCBc0 Message-ID: <47BEC04D.8040505@gmx.net> Date: Fri, 22 Feb 2008 14:30:05 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jan Seedorf References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu> <47BEAEE3.4040701@gmx.net> <113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office> <47BEB721.8040305@gmx.net> <113091BD57179D4491C19DA7E10CD69601B563A8@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD69601B563A8@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Jan, Jan Seedorf wrote: > Hi Hannes, > > >> Let's take an example: >> When Henning's host is compromised and a bot is using >> Henning's account to send me spam then I would contact >> Henning (by using various ways) to tell him that something is >> wrong with his PC/phone/etc. I would not tell my VoIP >> provider that there is something wrong with Henning's account. >> Typically, this will lead to more problems rather than less >> -- such as no communication to Columbia University anymore >> because my VoIP provider just blocks all calls from that domain. >> >> (Just to reflect my experience with email problems in the company....) >> > I understand these problems. And we need to discuss them. My point was just that with respect to "but at least the sender can be identified and fixed/fined/taken offline" the spam-feedback draft is a building block. You are suggesting that when a user presses a "this was SPIT" button, this does not trigger a message to the provider of the callee but instead an offline (e.g., email) message to the caller saying "hey, I received SPIT from your account, do something!". That is another way of using the feedback-mechanism, and quite interesting I would say. > > I fully agree that "automatic" and "aggressive" blocking as today in the e-mail world is a probelm we need to consider. > > The usage case of the SPIT reporting between the end host and the VoIP provider is not for Henning's case " - Uses credentials, spams addresses in addressbook: whitelists don't help, but at least the sender can be identified and fixed/fined/taken offline. " I don't want folks in my buddy list to get fined; I want to tell them that they have a problem with their PC. I don't need a protocol to tell them that. However, I see it being useful for reporting SPIT between providers in case of the following category: " - Uses credentials, but spews randomly: unlikely that the recipient will have that person in their whitelist, so still manageable. " and in the case where someone does not use a white list then he can obviously report something to it's VoIP provider when he does not know that person. Ciao Hannes > - Jan > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, February 22, 2008 12:51 PM >> To: Jan Seedorf >> Cc: Signaling TO Prevent SPIT; Brian Azzopardi; >> rucus@ietf.org; Juergen Quittek >> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft >> RUCUS charter >> >> Hi Jan, >> >> >> Jan Seedorf wrote: >> >>> Dear Hannes, >>> >>> >>> >>>> I think we should put Henning's classification somewhere in our >>>> documents. >>>> >>>> >>> I also like Henning's classification because it narrows >>> >> down where the problem with botnets regarding SPIT is. >> >>> >>> >>>>> - Uses credentials, spams addresses in addressbook: >>>>> >>>>> >>>> whitelists don't >>>> >>>> >>>>> help, but at least the sender can be identified and >>>>> >>>>> >>>> fixed/fined/taken >>>> >>>> >>>>> offline. >>>>> >>>>> >>> I fully agree: this is the problem and the "compromised >>> >> identity" then >> >>> needs to be identified and blocked. One question then is, >>> >> how can we >> >>> share the identification of a not-trustworthy identity (as >>> >> perceived >> >>> by end-users or domains) among SIP-entities/domains. One building >>> block I see here clearly is >>> >>> >> http://www.ietf.org/internet-drafts/draft-niccolini-sipping-spam-feedb >> >>> ack-00.txt >>> >>> >> Let's take an example: >> When Henning's host is compromised and a bot is using >> Henning's account to send me spam then I would contact >> Henning (by using various ways) to tell him that something is >> wrong with his PC/phone/etc. I would not tell my VoIP >> provider that there is something wrong with Henning's account. >> Typically, this will lead to more problems rather than less >> -- such as no communication to Columbia University anymore >> because my VoIP provider just blocks all calls from that domain. >> >> (Just to reflect my experience with email problems in the company....) >> >> >>> for giving users the possibility to indicate that some identity may >>> not be trustworthy anymore (e.g., because it got compromised in the >>> sense Henning describes above). Additionally, >>> http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 >>> and >>> >>> >> http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam-score-s >> >>> emantics-00.txt offer a solution for signalling such information >>> between entities. Note that in the semantics draft we tried >>> >> to point the importance of having a precise meaning >> associated with a SPIT score. >> >>> >>> >> I haven't read draft-seedorf-sipping-spam-score-semantics-00.txt yet. >> Comments later. >> >> >> Ciao >> Hannes >> >> >>> - Jan >>> >>> >>> >>>> -----Original Message----- >>>> From: spitstop-bounces@listserv.netlab.nec.de >>>> [mailto:spitstop-bounces@listserv.netlab.nec.de] On Behalf >>>> >> Of Hannes >> >>>> Tschofenig >>>> Sent: Friday, February 22, 2008 12:16 PM >>>> To: Signaling TO Prevent SPIT >>>> Cc: Brian Azzopardi; rucus@ietf.org; Juergen Quittek >>>> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft RUCUS >>>> charter >>>> >>>> I think we should put Henning's classification somewhere in our >>>> documents. >>>> >>>> I had a chat with Peter Saint-Andre this week and he reported me >>>> about problems they had with malicious users (potentially >>>> >> using the >> >>>> XMPP servers for file sharing) in their XMPP server >>>> >> infrastructure. >> >>>> He told me that their community is looking into a >>>> >> mechanism to allow >> >>>> one domain to report problems to another domain. This would >>>> correspond to Henning's 2nd category below and a >>>> >> mechanisms similar >> >>>> to the one described in >>>> http://www.ietf.org/internet-drafts/draft-niccolini-sipping-sp >>>> am-feedback-00.txt >>>> would be useful (expect that it would not be run between >>>> >> the end host >> >>>> and the VoIP provider but between two VoIP providers). >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: I put Peter on CC in case I misunderstood something. >>>> >>>> Henning Schulzrinne wrote: >>>> >>>> >>>>> There are three sub-cases of bot nets: >>>>> >>>>> - Just uses host, without credentials: identity-based >>>>> >> whitelisting >> >>>>> works (subject to the usual problems with whitelisting) >>>>> >>>>> - Uses credentials, but spews randomly: unlikely that the >>>>> >> recipient >> >>>>> will have that person in their whitelist, so still manageable. >>>>> >>>>> - Uses credentials, spams addresses in addressbook: >>>>> >>>>> >>>> whitelists don't >>>> >>>> >>>>> help, but at least the sender can be identified and >>>>> >>>>> >>>> fixed/fined/taken >>>> >>>> >>>>> offline. >>>>> >>>>> I'm not trying to downplay bot nets, just that this is a bit more >>>>> nuanced. >>>>> >>>>> Henning >>>>> >>>>> On Feb 20, 2008, at 3:37 AM, Brian Azzopardi wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Dan, >>>>>> >>>>>> I am afraid that we may have to hit the ground running. >>>>>> >>>>>> >>>> Email spam is >>>> >>>> >>>>>> already a big industry with well established operators. >>>>>> >>>>>> >>>> Spewing out >>>> >>>> >>>>>> SPIT instead of email spam is just another 'product' for them. >>>>>> Only amateur SPITers will use spitter and other such tools - the >>>>>> professional ones already have the infrastructure in place >>>>>> >>>>>> >>>> and they'd >>>> >>>> >>>>>> be irrational not to reuse it for SPIT - they will just short- >>>>>> circuit to your step 5. We do need to think deeply about >>>>>> >>>>>> >>>> botnets - >>>> >>>> >>>>>> they are the principal means of sending spam and have >>>>>> >> been for at >> >>>>>> least the last 2 years. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Brian Azzopardi - Senior Business Analyst GFI Software - >>>>>> >>>>>> >>>> www.gfi.com >>>> >>>> >>>>>> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On >>>>>> Behalf Of Dan York >>>>>> Sent: 19 February 2008 21:24 >>>>>> To: Juergen Quittek >>>>>> Cc: rucus@ietf.org; Signaling TO Prevent SPIT >>>>>> Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter >>>>>> >>>>>> Juergen (and Saverio and others), >>>>>> >>>>>> I appreciate the point you are raising here. My interest and >>>>>> passion are in networking, communication and security. To me, >>>>>> botnets are both incredibly fascinating and incredibly >>>>>> >>>>>> >>>> terrifying. >>>> >>>> >>>>>> I agree with you that botnets very certainly may be the biggest >>>>>> source of SIP spam in the future. >>>>>> >>>>>> Here's my problem: >>>>>> >>>>>> We have to crawl before we can walk and before we can run. >>>>>> >>>>>> Let's say that this is the (incredibly simplistic view of the) >>>>>> evolution of email spam: >>>>>> >>>>>> 1. Someone figures out that they can send advertisements >>>>>> >>>>>> >>>> to a range >>>> >>>> >>>>>> of email addresses they have collected. >>>>>> 2. Someone realizes that they can add those addresses to a >>>>>> >>>>>> >>>> "mailing >>>> >>>> >>>>>> list" to easily send to a large number of addresses. >>>>>> 3. Tools are developed that automate the collection of >>>>>> >>>>>> >>>> addresses and >>>> >>>> >>>>>> the sending out of messages. >>>>>> 4. At a certain time, there are enough people using email >>>>>> >>>>>> >>>> out there >>>> >>>> >>>>>> that this whole area of email advertising is a huge financial >>>>>> marketplace. Companies/entities set up server farms to >>>>>> >>>>>> >>>> just send out >>>> >>>> >>>>>> tons of email messages. (Defenders blacklist those servers.) 5. >>>>>> Those "servers" get distributed into massive botnets >>>>>> >>>>>> >>>> and are then >>>> >>>> >>>>>> able to avoid blacklisting, etc. >>>>>> >>>>>> I have absolutely no doubt that SIP spam will >>>>>> >>>>>> >>>> unfortunately follow >>>> >>>> >>>>>> the exact same trajectory. We're already seeing the tools to >>>>>> automate SPIT (here's one: >>>>>> >>>>>> >>>> http://www.hackingvoip.com/tools/spitter.tar.gz >>>> >>>> >>>>>> ). At some point we will hit my #4 when there are >>>>>> >> enough people >> >>>>>> using SIP *with publicly accessible SIP addresses* that it >>>>>> >>>>>> >>>> becomes >>>> >>>> >>>>>> financially lucrative enough for the larger automation >>>>>> >> to occur - >> >>>>>> and following on the heels of that will be the botnets. It will >>>>>> happen. To me it's not a question of IF but rather WHEN. >>>>>> >>>>>> Right now, though, we're still in my steps 1-3 as people >>>>>> >> start to >> >>>>>> get SIP endpoints and realize how they can abuse them. >>>>>> >>>>>> My concern about adding the focus on botnets into RUCUS is >>>>>> >>>>>> >>>> the fact >>>> >>>> >>>>>> that we can easily get distracted into looking at how to solve >>>>>> bigger issues and not get done the smaller issues that we can >>>>>> perhaps address today. >>>>>> >>>>>> Let's face it, probably all of us on this list would be >>>>>> >>>>>> >>>> categorized >>>> >>>> >>>>>> as early adopters who like to explore cutting edge >>>>>> >>>>>> >>>> technologies. We >>>> >>>> >>>>>> like to chase bright shiny objects and what is new and sexy and >>>>>> interesting. Let's say that you have a choice at the next >>>>>> >>>>>> >>>> IETF to >>>> >>>> >>>>>> listen to either: >>>>>> 1. a presentation on a SIP header to pass a "spam score" value >>>>>> between a SIP proxy and a UA; or 2. a presentation about SIP >>>>>> botnets, how they are constructed and the threats they pose. >>>>>> I would expect that probably 90% of us would choose the >>>>>> >>>>>> >>>> botnet talk. >>>> >>>> >>>>>> (No disrespect intended to the spam-score folks, just using an >>>>>> example.) The reality, though, is that the spam score discussion >>>>>> might be far more useful in moving us toward solutions that will >>>>>> help us with the people abusing SIP systems today. I >>>>>> >>>>>> >>>> don't want to >>>> >>>> >>>>>> wake up some day and find out that while we've been having >>>>>> >>>>>> >>>> a ton of >>>> >>>> >>>>>> discussions about botnets, some idiot meanwhile is repeatedly >>>>>> connecting to my SIP server and pumping our voicemail >>>>>> >>>>>> >>>> system full of >>>> >>>> >>>>>> SPIT. >>>>>> >>>>>> Maybe it's crazy on my part, but I want to see RUCUS have >>>>>> >>>>>> >>>> a charter >>>> >>>> >>>>>> that results in an achievable plan and architecture. >>>>>> >>>>>> Yes, we should consider botnets as a potential source of >>>>>> >> SIP spam >> >>>>>> and, yes, the potential existence of SIP botnets should be >>>>>> >>>>>> >>>> included >>>> >>>> >>>>>> in our thinking about an architecture to address SIP spam >>>>>> >>>>>> >>>> (so that >>>> >>>> >>>>>> any architecture we come up with does not discount dealing with >>>>>> botnets). But I also think we need to stay focused on >>>>>> >>>>>> >>>> what we can >>>> >>>> >>>>>> do now about the threats that are out there today (before >>>>>> >>>>>> >>>> it's too >>>> >>>> >>>>>> late). Let's crawl first, then walk, then run. >>>>>> >>>>>> My 2 cents, >>>>>> Dan >>>>>> >>>>>> On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote: >>>>>> Today, most of the spam email comes from bot-nets and recently >>>>>> email spammers started to send massively from compromized valid >>>>>> email accounts. I do not see why this would not become also the >>>>>> biggest source of SIP spam in the future. >>>>>> >>>>>> Consequently, we should address this issue when developing an >>>>>> architecture for reducing SIP spam in the RUCUS WG. The >>>>>> architecture should be general enough for covering also >>>>>> >> means that >> >>>>>> reduce SIP spam from bot nets and compromized accounts >>>>>> >>>>>> Whether or not to work on this problem is being discussed highly >>>>>> controversially in the IETF. But considering that the >>>>>> >> RUCUS BoF is >> >>>>>> targeted at establishing not a regular working group, but an RFC >>>>>> 5111 Exploratory Group, I do not think it would be >>>>>> >> appropriate to >> >>>>>> exclude such work from the beginning. >>>>>> >>>>>> It should rather be part of the exploratory work to find out >>>>>> whether or not reducing SIP spam from bot nets is a >>>>>> >> target worth to >> >>>>>> be attacked by the IETF. >>>>>> >>>>>> -- >>>>>> Dan York, CISSP, Director of Emerging Communication Technology >>>>>> Office of the CTO Voxeo Corporation dyork@voxeo.com >>>>>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>>>>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>>>>> >>>>>> Bring your web applications to the phone. >>>>>> Find out how at http://evolution.voxeo.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> DISCLAIMER >>>>>> The information contained in this electronic mail may be >>>>>> confidential or legally privileged. It is for the intended >>>>>> recipient(s) only. Should you receive this message in >>>>>> >>>>>> >>>> error, please >>>> >>>> >>>>>> notify the sender by replying to this mail. Unless >>>>>> >>>>>> >>>> expressly stated, >>>> >>>> >>>>>> opinions in this message are those of the individual >>>>>> >>>>>> >>>> sender and not >>>> >>>> >>>>>> of GFI. Unauthorized use of the contents is strictly >>>>>> >> prohibited. >> >>>>>> While all care has been taken, GFI is not responsible for the >>>>>> integrity of the contents of this electronic mail and any >>>>>> attachments included within. >>>>>> >>>>>> This mail was checked for viruses by GFI MailSecurity. GFI also >>>>>> develops anti-spam software (GFI MailEssentials), a fax >>>>>> >>>>>> >>>> server (GFI >>>> >>>> >>>>>> FAXmaker), and network security and management software (GFI >>>>>> LANguard) - www.gfi.com >>>>>> >>>>>> _______________________________________________ >>>>>> Rucus mailing list >>>>>> Rucus@ietf.org >>>>>> http://www.ietf.org/mailman/listinfo/rucus >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> spitstop mailing list >>>>> spitstop@listserv.netlab.nec.de >>>>> https://listserv.netlab.nec.de/mailman/listinfo/spitstop >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> spitstop mailing list >>>> spitstop@listserv.netlab.nec.de >>>> https://listserv.netlab.nec.de/mailman/listinfo/spitstop >>>> >>>> >>>> >> _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 04:33:50 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522C828C2F0; Fri, 22 Feb 2008 04:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9voQrCAkggN; Fri, 22 Feb 2008 04:33:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82AF828C30F; Fri, 22 Feb 2008 04:33:46 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AD953A6C5F for ; Fri, 22 Feb 2008 04:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+gPkL9rB4UD for ; Fri, 22 Feb 2008 04:33:41 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E579E3A6C16 for ; Fri, 22 Feb 2008 04:33:40 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 12:33:35 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp022) with SMTP; 22 Feb 2008 13:33:35 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/YjpMAynbYQiUXFzu6crP/FBcqsvKEp351RrG1kg YV2B5h3CVvknOR Message-ID: <47BEC12A.1070504@gmx.net> Date: Fri, 22 Feb 2008 14:33:46 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Saverio Niccolini References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu> <47BEAEE3.4040701@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF53DB88@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF53DB88@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org I know. These mechanisms are known from the email world and also from XMPP. But there is a some way to go between today's state of the art, namely largely no end-to-end SIP usage to a state where botnets steal your identity to bypass white lists. Ciao Hannes Saverio Niccolini wrote: > Hannes, all, > > >> I had a chat with Peter Saint-Andre this week and he reported >> me about problems they had with malicious users (potentially >> using the XMPP servers for file sharing) in their XMPP server >> infrastructure. He told me that their community is looking >> into a mechanism to allow one domain to report problems to >> another domain. This would correspond to Henning's 2nd >> category below and a mechanisms similar to the one described >> in >> http://www.ietf.org/internet-drafts/draft-niccolini-sipping-sp >> > am-feedback-00.txt > >> would be useful (expect that it would not be run between the >> end host and the VoIP provider but between two VoIP providers). >> > > Right, actually this is why we inserted this potential communication > interface in the SPITSTOP draft, see interface "b" among providers > in: > http://tools.ietf.org/html/draft-niccolini-sipping-spitstop-01#page-6 > > Saverio > > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 04:40:09 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D57928C340; Fri, 22 Feb 2008 04:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcVvFVPGHUWE; Fri, 22 Feb 2008 04:40:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8781E28C2FD; Fri, 22 Feb 2008 04:40:08 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0480228C301 for ; Fri, 22 Feb 2008 04:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SP303FZx1jqN for ; Fri, 22 Feb 2008 04:40:06 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C553828C2B8 for ; Fri, 22 Feb 2008 04:40:05 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 12:40:01 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp013) with SMTP; 22 Feb 2008 13:40:01 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19uQMhQtP9uABpdZDtkVF4Uqyb7kyDB9nEZu484tN JeWBdQUt974MkC Message-ID: <47BEC2A8.50201@gmx.net> Date: Fri, 22 Feb 2008 14:40:08 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Saverio Niccolini References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> DEFANGED[4]:<42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu><47BEAEE3.4040701@gmx.net><113091BD57179D4491C19DA7E10CD69601B5639F@mx1.offi " " ce> <47BEB721.8040305@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF53DB8D@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF53DB8D@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Saverio, Saverio Niccolini wrote: > Hannes, all, > > >> Let's take an example: >> When Henning's host is compromised and a bot is using >> Henning's account to send me spam then I would contact >> Henning (by using various ways) to tell him that something is >> wrong with his PC/phone/etc. I would not tell my VoIP >> provider that there is something wrong with Henning's account. >> Typically, this will lead to more problems rather than less >> -- such as no communication to Columbia University anymore >> because my VoIP provider just blocks all calls from that domain. >> >> (Just to reflect my experience with email problems in the company....) >> > > You do not contact Henning directly to tell him that something > is wrong. You have to rely on your infrastructure to take the > necessary countermeasures otherwise it is the anarchy... > Why wouldn't I contact him directly? > That is why exchanging reputation of identities (as perceived by > end-users or domains) is an important building block. > Such reputation system (one of the points of RFC 5039) can be built > using mechanisms like feedbacks: > http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 > and spam scores: > http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 > of course there are privacy issues that apply (but this is > a problem of reputation systems as well) :-) > There is a long way to go between a global reputation system and the drafts you mention above. > It seems this list is converging to the point we tried to raise > since 2006, I should be happy :-) > Nobody is saying that these mechanisms do not exist on paper. They just have a quite challenging deployment story and the protocol issue is the least problematic thing to worry about: it is the trust relationships you have to establish between the VoIP provider. If you think about a model similar to email then you will have a hard time to establish such an infrastructure. Ciao Hannes > Saverio > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > _______________________________________________ > spitstop mailing list > spitstop@listserv.netlab.nec.de > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 04:50:18 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B353028C30C; Fri, 22 Feb 2008 04:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m-e2vpuxCNA; Fri, 22 Feb 2008 04:50:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34D928C2EA; Fri, 22 Feb 2008 04:50:09 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4CB3A6842 for ; Fri, 22 Feb 2008 04:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwdz+V0GK+M7 for ; Fri, 22 Feb 2008 04:50:04 -0800 (PST) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 4AC1E3A6885 for ; Fri, 22 Feb 2008 04:50:04 -0800 (PST) Received: from roundabout.local (ip-213-49-227-39.dsl.scarlet.be [213.49.227.39]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTP id B96DF40340; Fri, 22 Feb 2008 05:49:43 -0700 (MST) Message-ID: <47BEC4F1.9010902@stpeter.im> Date: Fri, 22 Feb 2008 13:49:53 +0100 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Hannes.Tschofenig@gmx.net References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> <909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu> <47BEAEE3.4040701@gmx.net> In-Reply-To: <47BEAEE3.4040701@gmx.net> Cc: rucus@ietf.org, Signaling TO Prevent SPIT Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0918036036==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0918036036== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020602020702040701090506" This is a cryptographically signed message in MIME format. --------------ms020602020702040701090506 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hannes Tschofenig wrote: > I think we should put Henning's classification somewhere in our documents. > > I had a chat with Peter Saint-Andre this week and he reported me about > problems they had with malicious users (potentially using the XMPP > servers for file sharing) in their XMPP server infrastructure. He told > me that their community is looking into a mechanism to allow one domain > to report problems to another domain. This would correspond to Henning's > 2nd category below and a mechanisms similar to the one described in > http://www.ietf.org/internet-drafts/draft-niccolini-sipping-spam-feedback-00.txt > would be useful (expect that it would not be run between the end host > and the VoIP provider but between two VoIP providers). That's correct. An early version is here: http://www.xmpp.org/extensions/inbox/error-abuse.html > PS: I put Peter on CC in case I misunderstood something. I'm on both spitstop and rucus, but I confess to finding the continued sending to both lists a bit annoying. Can't we all just send to rucus (and not spitstop) now? :) Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms020602020702040701090506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODAyMjIxMjQ5NTNaMCMGCSqG SIb3DQEJBDEWBBQ8A4vazsAMwZhCO8wNZX81OsPv0zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQAo1z3WXMZmH8Id8vF1XNR4BMlxlA7LHbS3/wn+YCO6l5S8KLjnfsdo7iPHvhNV/Eom84+M lSVLOCPYOG49byoCY1J+wC05sqoJH0A4Z+8Q2vZREcsr/Fa4kAQ6iX6VeCqsh6TwNvz5Y2yf TYMpcqOzMYP810bmaz+r47hI91uTQVcb68GOTYfNM1oIWpz2hHeuA8bujDzXnsLB5ZgARp/n jHwLPsmeI2I/7GSLtplv8MOHba50982a64WNy5LppvFmdpncbiTk/5DCmvOSbTuYRdfmSNCn IABM+UszYDAfj4JVq981vlKvPv9fNaV8Uk0GwYmzP/t6pik+9IlMvlERAAAAAAAA --------------ms020602020702040701090506-- --===============0918036036== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============0918036036==-- From rucus-bounces@ietf.org Fri Feb 22 04:56:11 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00F428C2B8; Fri, 22 Feb 2008 04:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSdbgevuHnzv; Fri, 22 Feb 2008 04:56:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB753A6C49; Fri, 22 Feb 2008 04:56:10 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B5F928C282 for ; Fri, 22 Feb 2008 04:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0zYDf3eIp0Q for ; Fri, 22 Feb 2008 04:56:03 -0800 (PST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 7DE633A6842 for ; Fri, 22 Feb 2008 04:56:03 -0800 (PST) Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id m1MCtuqB009241; Fri, 22 Feb 2008 13:55:56 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id m1MCttAF004820; Fri, 22 Feb 2008 13:55:56 +0100 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 13:55:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 13:55:58 +0100 Message-ID: <198A10EC585EC74687BCA414E2A5971802093E20@MCHP7RDA.ww002.siemens.net> In-Reply-To: <47BEC03A.8070009@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] [Rucus] Botnets, take 2... Re: Draft RUCUS charter Thread-Index: Ach1UAAdVKbvFjJBRcO8mYOWgVZ9/AAAIK2A References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu><47BEAEE3.4040701@gmx.net><113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office> <47BEB721.8040305@gmx.net> <198A10EC585EC74687BCA414E2A5971802093DFC@MCHP7RDA.ww002.siemens.net> <47BEC03A.8070009@gmx.net> From: "Fischer, Kai" To: X-OriginalArrivalTime: 22 Feb 2008 12:55:55.0085 (UTC) FILETIME=[42EFF7D0:01C87552] Cc: rucus BoF , Jan Seedorf , Juergen Quittek Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Hannes, > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Freitag, 22. Februar 2008 13:30 > To: Fischer, Kai > Cc: rucus BoF; Jan Seedorf; Brian Azzopardi; rucus@ietf.org; > Juergen Quittek > Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft > RUCUS charter > > Hi Kai, > > Fischer, Kai wrote: > >> Let's take an example: > >> When Henning's host is compromised and a bot is using > >> Henning's account > >> to send me spam then I would contact Henning (by using > >> various ways) to > >> tell him that something is wrong with his PC/phone/etc. I > >> would not tell > >> my VoIP provider that there is something wrong with Henning's > >> account. > >> Typically, this will lead to more problems rather than less > >> -- such as > >> no communication to Columbia University anymore because my > >> VoIP provider > >> just blocks all calls from that domain. > >> > >> (Just to reflect my experience with email problems in the > company....) > >> > > > > I don't assume that the sender of spam usually is a person > I personally > > know and whom I want to contact directly (still more personal > > disturbance and effort). Applying very restrictive white > lists allowing > > only personal known people to contact me may be yes, but I > expect that > > this is not usual scenario (I have no email white list). > > > > > > The spammer is not known; however, for the case we are > considering here > the account of someone from your buddy list is being used for > spamming. > If you are spamming me then I would obviously get in touch > with you and > ask you what you want. I think the assumption that a spammer is using only the buddies of the captured account might be too limited. What does a spammer prevent to spam also other persons, for whom he found the addresses in public sources (and these people won't contact the 'captured' person directly to give feedback since it is not known to them). A countermeasure would be a white list, which configures that only buddy are allowed to make a call to me. But than I don't get calls from unknown persons, which I want to still receive. Yes, I can do an authorization request in advance, but is this not also a form of spam (and again I won't contact these persons directly). > > It is true that you have no email white list -- this is, however, a > drawback for email that we don't need to repeat again. > Consider Instant Messaging, for example, many people us a mixture > between white lists and black lists. Very common today! Yes and it is the grey zone between white and black which causes trouble. > For the PSTN there are obviously no white lists either > > Ciao > Hannes Kai _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 05:01:10 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1919528CB52; Fri, 22 Feb 2008 05:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhRCeBFZWTEj; Fri, 22 Feb 2008 05:01:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D9E3A6C5F; Fri, 22 Feb 2008 05:01:06 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621F528CA20 for ; Fri, 22 Feb 2008 05:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FnZS60ulpcA for ; Fri, 22 Feb 2008 05:00:59 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 670E628CB54 for ; Fri, 22 Feb 2008 05:00:53 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28122677; Fri, 22 Feb 2008 13:00:48 +0000 In-Reply-To: <47BEC4F1.9010902@stpeter.im> References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> <909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu> <47BEAEE3.4040701@gmx.net> <47BEC4F1.9010902@stpeter.im> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Dan York Date: Fri, 22 Feb 2008 08:00:45 -0500 To: Peter Saint-Andre X-Mailer: Apple Mail (2.753) Cc: rucus BoF Subject: [Rucus] Let's ONLY send to RUCUS now, please! (and drop SPITSTOP) Re: [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1453483791==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1453483791== Content-Type: multipart/alternative; boundary=Apple-Mail-219--107737485 --Apple-Mail-219--107737485 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 22, 2008, at 7:49 AM, Peter Saint-Andre wrote: > > I'm on both spitstop and rucus, but I confess to finding the continued > sending to both lists a bit annoying. Can't we all just send to rucus > (and not spitstop) now? :) +10 At this point in time RUCUS is now at 74 members and anyone on SPITSTOP who is NOT over on RUCUS has had **plenty** of notice that the discussion is moving to RUCUS (including Saverio's email to SPITSTOP directly mentioning this fact). Can we all please take the action that if we are replying to a message with BOTH lists on it that we *remove* SPITSTOP from the recipients? All of our already-overflowing inboxes will be much better for that. Thanks, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-219--107737485 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Feb 22, 2008, at 7:49 AM, Peter Saint-Andre = wrote:
I'm on both spitstop and rucus, = but I confess to finding the continued
sending = to both lists a bit annoying. Can't we all just send to rucus
(and not spitstop) now? = :)

+10

At this point in time = RUCUS is now at 74 members and anyone on SPITSTOP who is NOT over on = RUCUS has had **plenty** of notice that the discussion is moving to = RUCUS (including Saverio's email to SPITSTOP directly mentioning this = fact).

Can = we all please take the action that if we are replying to a message with = BOTH lists on it that we *remove* SPITSTOP from the = recipients?

All of our = already-overflowing inboxes will be much better for that.

Thanks,
Dan=A0

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.




= --Apple-Mail-219--107737485-- --===============1453483791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1453483791==-- From rucus-bounces@ietf.org Fri Feb 22 05:13:55 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF1F3A6C84; Fri, 22 Feb 2008 05:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL8SSIO1sU8T; Fri, 22 Feb 2008 05:13:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61CF928C33C; Fri, 22 Feb 2008 05:13:53 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25AF028C3F5 for ; Fri, 22 Feb 2008 05:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3iL8NHK66aV for ; Fri, 22 Feb 2008 05:13:46 -0800 (PST) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 5FB8A28C381 for ; Fri, 22 Feb 2008 05:13:11 -0800 (PST) Received: from roundabout.local (ip-213-49-227-39.dsl.scarlet.be [213.49.227.39]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTP id 9FE8340340; Fri, 22 Feb 2008 06:12:53 -0700 (MST) Message-ID: <47BECA5B.9060503@stpeter.im> Date: Fri, 22 Feb 2008 14:12:59 +0100 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Hannes.Tschofenig@gmx.net References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <5F6519BF2DE0404D99B7C75607FF76FF4D11DA@mx1.office> <55DE3E54-6421-4632-AABE-D171D5D6E346@voxeo.com> <47BEB2FF.9060304@gmx.net> In-Reply-To: <47BEB2FF.9060304@gmx.net> Cc: rucus@ietf.org Subject: Re: [Rucus] EG vs WG - Re: [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2135805922==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============2135805922== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080701030001020708090708" This is a cryptographically signed message in MIME format. --------------ms080701030001020708090708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hannes Tschofenig wrote: > I agree with Dan but at the same time I also agree with Saverio. > > Here is the issue: Difficult security challenges often require > complicated solutions. > > The evil guy will pick the easy target's first. For me, an easy > indication about the success of a specific technology is when you get > the first spam. For example, when I look at my blog, Wiki, or roundup > issue tracker then I have to admit that they are pretty successful on > the Internet. Spammer exploit them. It would not make sense to target > them if only a few folks use them. Hence, you raise the bar. Instead of > allowing everyone to post comments and to register themself you put some > additional mechanisms in place -- these mechanisms will typically be > inconvenient for the users (for example, they have to go through a > CAPTCHA test before posting something, posting is only allowed for > members; I have to add them manually to the access control list, etc.). > > The XMPP experience tells us something about this already and they use > an email alike style of communication (hence they don't even have > something like SIP Identity). The simple techniques work fine at the > beginning but you have to raise the bar for the adversary as your > technology becomes more successful. Email Spammers could just easily use > their existing botnets and apply them to XMPP; sure. They did not do it > because it does not create enough revenue for them -- email, Wiki's and > Weblogs are much better. It might sound ironic but we have to make sure > that the evil guys pick someone else and not SIP. The way I put it is this: you don't have to be the fastest antelope in the pack, but you had better not be among the slowest. :) The main spam we've seen has been in groupchat rooms. In part this may be because some of our rooms are archived, so that the conversations are viewable on the web -- post links and have your spam immortalized for all time (except we scrub the logs). In part it may be because rooms feel semi-anonymous or IRC-like. In part it may be because you can annoy more people this way. We have also seen abusive traffic of a more nebulous nature (is it a file sharing network, is it a botnet, is it some kind of distributed application?), but that has not been spam-like as far as we can tell. > In our work we clearly need to differentiate between implementing and > deploying it vs. writing documents. We can obviously quite easily write > documents that address almost every problem we can imagine. That's not > the issue. The challenge begins when all the stuff has to be deployed. > When someone who hasn't followed IETF mailing list discussions suddenly > sees 50 different mechanisms and extensions they will be confused. What > should they do? They will not implement all; particularly not if they do > not yet have a lot of problems. They will have to implement things > incrementally. What should they start with? IMHO it's critically important to have very good communication and collaboration between developers, spec writers, and operators. I know we've tried to maintain that in the XMPP community, but I don't have as clear a handle on that in the SIP world. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms080701030001020708090708 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODAyMjIxMzEyNTlaMCMGCSqG SIb3DQEJBDEWBBRK9OTHKkTn4H4p88tBz/wjZS6lyjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQADBaqrQ8WySWC+Wb5adJ1zGIuCvGhfV/4H6csDNr+hOLsuk7EnmXgs53afAgHPRn0nptk9 A13rdo3SYRIi7oM1Ai5R3lUDrWVMa3i4HgvrgLLbHCfEmsqyFIHw4ydjKgnaddPwJdwcdlp5 FR7TpU8fVrJdrbOlAppT2pn3+bwe2CfgM7BOef9fhUwCcfIj+grD0DTKbW86mqx6uXYnWyu2 R62R4ekPr5VKCMBm8lWVP8gY9k4lqBwV0IJER66LXMSBpeuhaIe7e7OFit+Ixk+i1zjZgwXl xW3fyj+MRXWXjHWLqKOjQEH/k9FGiQefuPeoTYiJdUAYXsSYUG9/XvCuAAAAAAAA --------------ms080701030001020708090708-- --===============2135805922== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============2135805922==-- From rucus-bounces@ietf.org Fri Feb 22 05:25:42 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A133A6CF2; Fri, 22 Feb 2008 05:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 846rqh1RPptv; Fri, 22 Feb 2008 05:25:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174083A6CBD; Fri, 22 Feb 2008 05:25:41 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AA93A6CBE for ; Fri, 22 Feb 2008 05:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KojybHVRtb0v for ; Fri, 22 Feb 2008 05:25:39 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A327628C2FA for ; Fri, 22 Feb 2008 05:25:38 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 13:25:33 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp046) with SMTP; 22 Feb 2008 14:25:33 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19IYpVVUNtIPgqfq5SbPTfcpqugk6n7uQ2x2v3YKb wkw0l8dzZaw4Vu Message-ID: <47BECD47.2030809@gmx.net> Date: Fri, 22 Feb 2008 15:25:27 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Fischer, Kai" References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu><47BEAEE3.4040701@gmx.net><113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office> <47BEB721.8040305@gmx.net> <198A10EC585EC74687BCA414E2A5971802093DFC@MCHP7RDA.ww002.siemens.net> <47BEC03A.8070009@gmx.net> <198A10EC585EC74687BCA414E2A5971802093E20@MCHP7RDA.ww002.siemens.net> In-Reply-To: <198A10EC585EC74687BCA414E2A5971802093E20@MCHP7RDA.ww002.siemens.net> X-Y-GMX-Trusted: 0 Cc: rucus BoF , Jan Seedorf , Juergen Quittek Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Kai, Fischer, Kai wrote: > Hi Hannes, > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Freitag, 22. Februar 2008 13:30 >> To: Fischer, Kai >> Cc: rucus BoF; Jan Seedorf; Brian Azzopardi; rucus@ietf.org; >> Juergen Quittek >> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft >> RUCUS charter >> >> Hi Kai, >> >> Fischer, Kai wrote: >> >>>> Let's take an example: >>>> When Henning's host is compromised and a bot is using >>>> Henning's account >>>> to send me spam then I would contact Henning (by using >>>> various ways) to >>>> tell him that something is wrong with his PC/phone/etc. I >>>> would not tell >>>> my VoIP provider that there is something wrong with Henning's >>>> account. >>>> Typically, this will lead to more problems rather than less >>>> -- such as >>>> no communication to Columbia University anymore because my >>>> VoIP provider >>>> just blocks all calls from that domain. >>>> >>>> (Just to reflect my experience with email problems in the >>>> >> company....) >> >>>> >>>> >>> I don't assume that the sender of spam usually is a person >>> >> I personally >> >>> know and whom I want to contact directly (still more personal >>> disturbance and effort). Applying very restrictive white >>> >> lists allowing >> >>> only personal known people to contact me may be yes, but I >>> >> expect that >> >>> this is not usual scenario (I have no email white list). >>> >>> >>> >> The spammer is not known; however, for the case we are >> considering here >> the account of someone from your buddy list is being used for >> spamming. >> If you are spamming me then I would obviously get in touch >> with you and >> ask you what you want. >> > > I think the assumption that a spammer is using only the buddies of the > captured account might be too limited. I was not saying that. We started with a discussion about botnets and there were claims that whitelists are useless with botnets. Henning clarified that and described in what cases botnets have a negative impact on whitelist behavior. > What does a spammer prevent to > spam also other persons, for whom he found the addresses in public > sources (and these people won't contact the 'captured' person directly > to give feedback since it is not known to them). > That's obviously something they can easily do. Here comes the overall story into play: What are the underlying mechanisms we assume that are present? If you assume that there are white lists in place then this will not cause too many problems; If you assume that there are no white lists (as it is the case for the PSTN today) then you obviously run into a couple of challenges. > A countermeasure would be a white list, which configures that only buddy > are allowed to make a call to me. But than I don't get calls from > unknown persons, which I want to still receive. Yes, I can do an > authorization request in advance, but is this not also a form of spam > (and again I won't contact these persons directly). > True. It is also a form of spam but certainly less annoying than calls in the middle of the night. There is obviously a tradeoff here. Consider current Instant Messaging behavior: You can change your context when you like. Sometimes you want to get contacted from unknown persons and sometimes you don't. If you disable your whitelist and you suddenly get contacted by someone and it turns out that you don't like that person then it is your problem. This is, however, a bit oversimplified since there are user types that cannot reject calls, such as people those folks answering your emergency call. They obviously have a hard time with white lists. Hence, we are looking at ways how to deal with these special user groups separately -- this is, for example, work done in ECRIT. One important aspect is to deal with unauthenticated emergency calls or with calls that have contain faked location information since the attack would be primarily against the first responders (not the call taker itself). > >> It is true that you have no email white list -- this is, however, a >> drawback for email that we don't need to repeat again. >> Consider Instant Messaging, for example, many people us a mixture >> between white lists and black lists. Very common today! >> > > Yes and it is the grey zone between white and black which causes > trouble. > Sure. Both forms of access control lists have drawbacks. We discussed these aspects extensively when we worked on Common Policy and Presence Authorization Policy. > >> For the PSTN there are obviously no white lists either >> >> Ciao >> Hannes >> > > Ciao Hannes > Kai > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 05:42:53 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CBCC28C332; Fri, 22 Feb 2008 05:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9CCP2FSDmD1; Fri, 22 Feb 2008 05:42:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846DA3A6C98; Fri, 22 Feb 2008 05:42:52 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F70128C243 for ; Fri, 22 Feb 2008 05:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWqKThFKVoA5 for ; Fri, 22 Feb 2008 05:42:49 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 12B303A6B96 for ; Fri, 22 Feb 2008 05:42:45 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2008 13:42:41 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp050) with SMTP; 22 Feb 2008 14:42:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18yM7laJKIyN2E+9HCMI1scd/gWcD0Sr8NxYkveTX dw55UqqtVEZJR2 Message-ID: <47BED14A.6080000@gmx.net> Date: Fri, 22 Feb 2008 15:42:34 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Peter Saint-Andre References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <5F6519BF2DE0404D99B7C75607FF76FF4D11DA@mx1.office> <55DE3E54-6421-4632-AABE-D171D5D6E346@voxeo.com> <47BEB2FF.9060304@gmx.net> <47BECA5B.9060503@stpeter.im> In-Reply-To: <47BECA5B.9060503@stpeter.im> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] EG vs WG - Re: [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > IMHO it's critically important to have very good communication and > collaboration between developers, spec writers, and operators. We are extremely good at that part. _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 06:08:32 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9B728C10C; Fri, 22 Feb 2008 06:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUwqYuR72bfV; Fri, 22 Feb 2008 06:08:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1918328C282; Fri, 22 Feb 2008 06:08:26 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AAA3A6B34 for ; Fri, 22 Feb 2008 06:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wstjTPnFa1Gn for ; Fri, 22 Feb 2008 06:08:22 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 4DB783A6CF9 for ; Fri, 22 Feb 2008 06:08:07 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28123952; Fri, 22 Feb 2008 14:08:01 +0000 In-Reply-To: <47BECA5B.9060503@stpeter.im> References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <5F6519BF2DE0404D99B7C75607FF76FF4D11DA@mx1.office> <55DE3E54-6421-4632-AABE-D171D5D6E346@voxeo.com> <47BEB2FF.9060304@gmx.net> <47BECA5B.9060503@stpeter.im> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <1BC17948-0C6A-44F9-AC4D-50A5EB7053AF@voxeo.com> From: Dan York Date: Fri, 22 Feb 2008 09:07:59 -0500 To: Peter Saint-Andre X-Mailer: Apple Mail (2.753) Cc: rucus@ietf.org Subject: Re: [Rucus] EG vs WG - Re: [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1973210935==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1973210935== Content-Type: multipart/alternative; boundary=Apple-Mail-226--103703775 --Apple-Mail-226--103703775 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 22, 2008, at 8:12 AM, Peter Saint-Andre wrote: > > The way I put it is this: you don't have to be the fastest antelope in > the pack, but you had better not be among the slowest. :) DY> The other way I've heard it is - what do you do if you and a friend are being chased by a bear? Just make sure you run faster than he does! > The main spam we've seen has been in groupchat rooms. In part this may > be because some of our rooms are archived, so that the > conversations are > viewable on the web -- post links and have your spam immortalized for > all time (except we scrub the logs). In part it may be because rooms > feel semi-anonymous or IRC-like. In part it may be because you can > annoy > more people this way. > > We have also seen abusive traffic of a more nebulous nature (is it a > file sharing network, is it a botnet, is it some kind of distributed > application?), but that has not been spam-like as far as we can tell. DY> Thank you for sharing the XMPP experience. As others have already said, learning from how other protocols have dealt with this is critical so you feedback and insight is definitely appreciated. > IMHO it's critically important to have very good communication and > collaboration between developers, spec writers, and operators. I know > we've tried to maintain that in the XMPP community, but I don't > have as > clear a handle on that in the SIP world. DY> If only we could.... The reality is that everybody and their brothers/sisters/mothers/fathers/uncles/aunts are all working with SIP in various forms. The larger vendors and operators realize the value of standards and participate in the IETF and other SDOs to varying degrees. The larger they are, the more interop they do and therefore the more they care about standards. Some startups are very concerned about standards, too, as well as a range of companies in between. DY> Those of us who *are* involved with IETF are well connected and I think there is a high degree of good communication and collaboration. DY> But then there are the zillion other companies that don't really care about standards (or don't understand them), simply want to make a buck, and take whatever paths they need to in order to get ahead. The world of "SIP trunking" is a bit like the proverbial "Wild West" right now with a whole crop of companies throwing softswitch/PBX software on some cheap PCs, buying upstream connectivity from one of the larger operators and... ta da... they're in the "SIP trunking" business offering cheaper PSTN connectivity. You have a ton of new entrants offering SIP wired or WiFi handsets. Some of those companies are attentive to standards. Some don't understand IETF and just implement whatever RFCs or I-Ds they think they need to. There's a lot of software companies out there that want to get into the "unified communications" game or want to tag along with Microsoft OCS or IBM Sametime that are throwing SIP interfaces onto applications without really understanding it all. As the results of the recent SIPit events show, we're getting *better* with SIP interop but we've still got a long way to go on many aspects. (And of course we don't really help this in some ways... how many RFCs are we up to for "SIP"? How many pages was Jonathan's last "Hitchhiker's Guide to SIP"?) DY> I believe we do need to encourage MORE companies to become involved (and make it easier for them to understand HOW to become involved). I like the work groups like SIP Forum are doing with their SIPconnect initiative to try to help companies understand the "correct" way to implement SIP. More efforts like that and introductory/howto documents will only continue to help. DY> In the meantime, I think there will continue to be the natural tension between those of us who implement RFCs correctly and are involved with the standards efforts and those out there who (out of lack of understanding or lack of caring) implement whatever they feel they need to in whatever way they think they need to. Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-226--103703775 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Feb 22, 2008, at 8:12 AM, Peter Saint-Andre = wrote:

The way I put it is this: you = don't have to be the fastest antelope in
the = pack, but you had better not be among the slowest. = :)

DY> The other way I've heard = it is - what do you do if you and a friend are being chased by a bear? = Just make sure you run faster than he does!

The = main spam we've seen has been in groupchat rooms. In part this = may
be because some of our rooms are = archived, so that the conversations are
viewable = on the web -- post links and have your spam immortalized for
all time (except we scrub the logs). In part it may = be because rooms
feel semi-anonymous or IRC-like. = In part it may be because you can annoy
more = people this way.

We have also seen abusive traffic of a more nebulous = nature (is it a
file sharing network, is it a = botnet, is it some kind of distributed
DY> Thank you for sharing = the XMPP experience. =A0As others have already said, learning from how = other protocols have dealt with this is critical so you feedback and = insight is definitely appreciated.

collaboration between = developers, spec writers, and operators. I know
we've tried to maintain that in the XMPP community, = but I don't have as
clear a handle on that in = the SIP world.

DY> =A0If only we could.... = =A0 The reality is that everybody and their = brothers/sisters/mothers/fathers/uncles/aunts are all working with SIP = in various forms. =A0The larger vendors and operators realize the value = of standards and participate in the IETF and other SDOs to varying = degrees. The larger they are, the more interop they do and therefore the = more they care about standards. =A0Some startups are very concerned = about standards, too, as well as a range of companies in = between.

DY> Those of us who = *are* involved with IETF are well connected and I think there is a high = degree of good communication and collaboration.

DY> But then there are = the zillion other companies that don't really care about standards (or = don't understand them), simply want to make a buck, and take whatever = paths they need to in order to get ahead. =A0The world of "SIP trunking" = is a bit like the proverbial "Wild West" right now with a whole crop of = companies throwing softswitch/PBX software on some cheap PCs, buying = upstream connectivity from one of the larger operators and... ta da... = they're in the "SIP trunking" business offering cheaper PSTN = connectivity. =A0You have a ton of new entrants offering SIP wired or = WiFi handsets. Some of those companies are attentive to standards. Some = don't understand IETF and just implement whatever RFCs or I-Ds they = think they need to. =A0There's a lot of software companies out there = that want to get into the "unified communications" game or want to tag = along with Microsoft OCS or IBM Sametime that are throwing SIP = interfaces onto applications without really understanding it all. As the = results of the recent SIPit events show, we're getting *better* with SIP = interop but we've still got a long way to go on many aspects. =A0(And of = course we don't really help this in some ways... how many RFCs are we up = to for "SIP"? How many pages was Jonathan's last "Hitchhiker's Guide to = SIP"?)

DY> = I believe we do need to encourage MORE companies to become involved (and = make it easier for them to understand HOW to become involved). =A0I like = the work groups like SIP Forum are doing with their SIPconnect = initiative to try to help companies understand the "correct" way to = implement SIP. =A0More efforts =A0like that and introductory/howto = documents will only continue to help.

DY> In the meantime, I think = there will continue to be the natural tension between those of us who = implement RFCs correctly and are involved with the standards efforts and = those out there who (out of lack of understanding or lack of caring) = implement whatever they feel they need to in whatever way they think = they need to.

Regards,
Dan
=

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-226--103703775-- --===============1973210935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1973210935==-- From rucus-bounces@ietf.org Fri Feb 22 07:07:59 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710FA28C1D4; Fri, 22 Feb 2008 07:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwO+7zGxMqWS; Fri, 22 Feb 2008 07:07:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E0A428C2FA; Fri, 22 Feb 2008 07:07:55 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508DB3A6808 for ; Fri, 22 Feb 2008 07:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKUE1qPDQtkx for ; Fri, 22 Feb 2008 07:07:52 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 3E19B28C3F5 for ; Fri, 22 Feb 2008 07:07:47 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1MF7fIh018928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 16:07:41 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1MF6psr014351; Fri, 22 Feb 2008 16:07:41 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 16:07:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 16:07:32 +0100 Message-ID: In-Reply-To: <47BEC03A.8070009@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter Thread-Index: Ach1Tp3xnxcpjRiiRh2+KGWrHQQeFwAFR61A References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu><47BEAEE3.4040701@gmx.net><113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office><47BEB721.8040305@gmx.net><198A10EC585EC74687BCA414E2A5971802093DFC@MCHP7RDA.ww002.siemens.net> <47BEC03A.8070009@gmx.net> From: "Charzinski, Joachim (NSN - DE/Muenich)" To: , "Fischer, Kai" X-OriginalArrivalTime: 22 Feb 2008 15:07:33.0340 (UTC) FILETIME=[A6AA09C0:01C87564] Cc: rucus@ietf.org, Jan Seedorf , Juergen Quittek Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Hannes, > For the PSTN there are obviously no white lists either > = not quite. A lot of PSTN switches should have white lists = already, it is just a question = - if the operators allow user administration and - if the users really appreciate using a voice interface = or a separate web login to administer those lists Best regards Joachim. = ---------------------------------------------------------- Nokia Siemens Networks Joachim Charzinski Principal Innovator Visitor address: Machtlfinger Str. 1 / D-81379 Muenchen / Germany Postal address: D-80240 Muenchen / Germany Tel: +49 89 722 46803 / Joachim.Charzinski@nsn.com / http://www.nokiasiemen= snetworks.com/global/ = Think before you print Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft: M=FCnchen / R= egistered office: Munich - Registergericht: M=FCnchen / Commercial registry= : Munich, HRA 88537 - WEEE-Reg.-Nr.: DE 52984304 - Pers=F6nlich haftende Ge= sellschafterin / General Partner: Nokia Siemens Networks Management GmbH - = Gesch=E4ftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer - S= itz der Gesellschaft: M=FCnchen / Registered office: Munich - Registergeric= ht: M=FCnchen / Commercial registry: Munich, HRB 163416 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 10:08:56 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725D428C402; Fri, 22 Feb 2008 10:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOUkocjiYYFc; Fri, 22 Feb 2008 10:08:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8518928C642; Fri, 22 Feb 2008 10:08:42 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A603428C33F for ; Fri, 22 Feb 2008 10:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1OFeFjtV+rV for ; Fri, 22 Feb 2008 10:08:38 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 6AC3528C8C8 for ; Fri, 22 Feb 2008 10:07:45 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 137B52C000357 for ; Fri, 22 Feb 2008 19:07:41 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWYZD9BP3ST2 for ; Fri, 22 Feb 2008 19:07:41 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 02C0F2C000355 for ; Fri, 22 Feb 2008 19:07:36 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 19:07:35 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DBF2@mx1.office> In-Reply-To: <47BEC4F1.9010902@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] [Rucus] Botnets, take 2... Re: Draft RUCUS charter Thread-Index: Ach1UYGhNv5wrbg/TkCxa/XPBtrp9gALCHHw References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu><47BEAEE3.4040701@gmx.net> <47BEC4F1.9010902@stpeter.im> From: "Saverio Niccolini" To: Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > > I had a chat with Peter Saint-Andre this week and he > reported me about > > problems they had with malicious users (potentially using the XMPP > > servers for file sharing) in their XMPP server > infrastructure. He told > > me that their community is looking into a mechanism to allow one > > domain to report problems to another domain. This would > correspond to > > Henning's 2nd category below and a mechanisms similar to the one > > described in > > > http://www.ietf.org/internet-drafts/draft-niccolini-sipping-spam-feedb > > ack-00.txt would be useful (expect that it would not be run between > > the end host and the VoIP provider but between two VoIP providers). > > That's correct. An early version is here: > > http://www.xmpp.org/extensions/inbox/error-abuse.html Then we agree that similar things should be there also for SIP and for RUCUS. Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 10:23:00 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44753A6CD7; Fri, 22 Feb 2008 10:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_UNSUB30=0.351, SARE_UNSUB30B=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EplyGPgJZfBI; Fri, 22 Feb 2008 10:22:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B9C28C366; Fri, 22 Feb 2008 10:22:59 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AECB3A67F3 for ; Fri, 22 Feb 2008 10:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idwmcFWTNV2m for ; Fri, 22 Feb 2008 10:22:51 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 177073A684C for ; Fri, 22 Feb 2008 10:22:51 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id BA5382C000357 for ; Fri, 22 Feb 2008 19:22:46 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYHHkJUCk7ma for ; Fri, 22 Feb 2008 19:22:46 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 9EFC32C000355 for ; Fri, 22 Feb 2008 19:22:41 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 19:22:40 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DBF3@mx1.office> In-Reply-To: <47BEC2A8.50201@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spitstop] [Rucus] Botnets, take 2... Re: Draft RUCUS charter Thread-Index: Ach1UA/xSBrEa3+bSJ6KekG83sYFhgALcnMw References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> DEFANGED[1]:DEFANGED[4]:<42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu><47BEAEE3.4040701@gmx.net><113091BD57179D4491C19DA7E10CD69601B56 " " 39F@mx1.offi " " ce> <47BEB721.8040305@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF53DB8D@mx1.office> <47BEC2A8.50201@gmx.net> From: "Saverio Niccolini" To: Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > > You do not contact Henning directly to tell him that something is > > wrong. You have to rely on your infrastructure to take the > necessary > > countermeasures otherwise it is the anarchy... > > > Why wouldn't I contact him directly? -1- you are saying that if people in the world receive 1.000.000 spam calls then they should generate an equal number of calls to let the other people know? I am sure there are more intelligent things to do than that... -2- have you ever heard of reflection attacks when reading about DoS, what if the purpose of the compromised account is not only to deliver you a telemarketing call but also to move people to bring down Henning's phone by calling him back? I hope these two are enough to understand that what you suggest is in principle NOT the solution... > > That is why exchanging reputation of identities (as perceived by > > end-users or domains) is an important building block. > > Such reputation system (one of the points of RFC 5039) can be built > > using mechanisms like feedbacks: > > http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 > > and spam scores: > > http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 > > of course there are privacy issues that apply (but this is > a problem > > of reputation systems as well) :-) > > > There is a long way to go between a global reputation system > and the drafts you mention above. I thought we are talking about the general architecture and its building blocks... Those are building blocks that belong to the general architecture. The way is long and if we wait until it is too late there will be no end to the road, better start now then... > > It seems this list is converging to the point we tried to > raise since > > 2006, I should be happy :-) > > > Nobody is saying that these mechanisms do not exist on paper. > They just have a quite challenging deployment story and the > protocol issue is the least problematic thing to worry about: > it is the trust relationships you have to establish between > the VoIP provider. If you think about a model similar to > email then you will have a hard time to establish such an > infrastructure. Are you saying that a model with white lists for calls would be more acceptable then? That my mother (even if she learnt how to use the PC since I am living abroad just to stay in contact with me) would configure her white list and switch its authorization policies every time she wants to be contacted by unknown people? Are you aware of how many people nowadays do not use properly presence indicators? (even skilled people) I would say my mother would rely on the provider to filter the vary bad calls on her behalf (using some sort of spam score and reputation system) and if she receives a spam call every now and then she would be able to press a button on her phone for "spam feedback" And of course, she has some authorization policies (but not the one: receive call only from white list...) That is why the "white list" concept is not enough without the "black list" concept. and I think it would be nonsense for RUCUS to focus only on "white list" and related architecture (remember that reputation is both "white" and "black"...) Saverio > > Ciao > Hannes > > > Saverio > > > > ============================================================ > > Dr. Saverio Niccolini > > Senior Researcher > > NEC Laboratories Europe, Network Research Division > > Kurfuerstenanlage 36, D-69115 Heidelberg > > Tel. +49 (0)6221 4342-118 > > Fax: +49 (0)6221 4342-155 > > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > > ============================================================ > > NEC Europe Limited Registered Office: NEC House, 1 Victoria > > Road, London W3 6BL Registered in England 2832014 > > > > _______________________________________________ > > spitstop mailing list > > spitstop@listserv.netlab.nec.de > > https://listserv.netlab.nec.de/mailman/listinfo/spitstop > > > > ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 11:58:58 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D732A3A6CF2; Fri, 22 Feb 2008 11:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=-2.272, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhM8MkBaNxV2; Fri, 22 Feb 2008 11:58:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE33128C900; Fri, 22 Feb 2008 11:57:17 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532B928C282 for ; Fri, 22 Feb 2008 11:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYfAoovA6x2q for ; Fri, 22 Feb 2008 11:57:14 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6595128C6FC for ; Fri, 22 Feb 2008 11:53:04 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 22 Feb 2008 11:53:00 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1MJr04u027943; Fri, 22 Feb 2008 11:53:00 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id m1MJr0hn017030; Fri, 22 Feb 2008 19:53:00 GMT Message-Id: <8651E525-0D5B-4C50-9DE0-7698915EDDF1@cisco.com> From: Cullen Jennings To: rucus@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 22 Feb 2008 11:52:49 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=213; t=1203709980; x=1204573980; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Chair=20for=20RUCUS=20BOF |Sender:=20; bh=GJivaTNGHYHQMid2g0h3x7De49NgVMbvL+TsCYBXqVw=; b=lXAbL7iT3zzN6PD+FEUupg5nhXEXhZnai49dGwvH1W6FxtBMCeRNapPYlX 3AJzXXACdNfETItQNP+0eOxKS5jDuDJqgphWx4gWpmAlQJEwK5E855/AUkIH 0W8zX164vQ; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Francois Audet Subject: [Rucus] Chair for RUCUS BOF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org I am very pleased to let folks know that Francois and Hannes have agreed to run the RUCUS BOF and will be the co-chairs of the BOF. Thanks to everyone for all the work going into this Cullen _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 12:49:41 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F02BF28C411; Fri, 22 Feb 2008 12:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbyD5XHDualb; Fri, 22 Feb 2008 12:49:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309453A6CC5; Fri, 22 Feb 2008 12:49:41 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4EC428C3F3 for ; Fri, 22 Feb 2008 12:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwzc30hYTiHn for ; Fri, 22 Feb 2008 12:49:39 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id CF0E03A6CC5 for ; Fri, 22 Feb 2008 12:49:38 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 01FA14D602; Fri, 22 Feb 2008 21:49:32 +0100 (CET) Date: Fri, 22 Feb 2008 21:49:32 +0100 From: Otmar Lendl To: rucus@ietf.org Message-ID: <20080222204932.GA1983@bofh.priv.at> References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com> <909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu> <47BEAEE3.4040701@gmx.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <47BEAEE3.4040701@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/22 12:02, Hannes Tschofenig wrote: > > I had a chat with Peter Saint-Andre this week and he reported me about > problems they had with malicious users (potentially using the XMPP > servers for file sharing) in their XMPP server infrastructure. He told > me that their community is looking into a mechanism to allow one domain > to report problems to another domain. This would correspond to Henning's > 2nd category below and a mechanisms similar to the one described in > http://www.ietf.org/internet-drafts/draft-niccolini-sipping-spam-feedback-00.txt > would be useful (expect that it would not be run between the end host > and the VoIP provider but between two VoIP providers). I'm wondering what these kinds of feedback systems can do if either * it's easy for the spitter to create new identities within the same domain * it's easy for the spitter to create his own domain, and thus he - can follow the protocol, and mint new indentities for each SPIT-run - or just forge the anti-spit feedback headers to indicate that no bad feedback had been received for this identity In other words, don't all these ideas assume the the miscreants are misbehaving clients using trustworthy service providers (which don't allow mass-minting of accounts?)? /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 12:58:23 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936E528C2BD; Fri, 22 Feb 2008 12:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.632 X-Spam-Level: X-Spam-Status: No, score=-0.632 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDgpTGQHyGKi; Fri, 22 Feb 2008 12:58:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B5728C374; Fri, 22 Feb 2008 12:58:22 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85C93A6BCE for ; Fri, 22 Feb 2008 12:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsV+3X7GSVzK for ; Fri, 22 Feb 2008 12:58:15 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 5CC0F28C2EB for ; Fri, 22 Feb 2008 12:56:47 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 138294D603; Fri, 22 Feb 2008 21:56:42 +0100 (CET) Date: Fri, 22 Feb 2008 21:56:42 +0100 From: Otmar Lendl To: rucus@ietf.org Message-ID: <20080222205642.GB1983@bofh.priv.at> References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <47BEAEE3.4040701@gmx.net> <113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/22 12:02, Jan Seedorf wrote: > > > I think we should put Henning's classification somewhere in > > our documents. > I also like Henning's classification because it narrows down where the problem with botnets regarding SPIT is. Same here, Henning's classification is really helpful. Reading the last 30 mails here on the list I have the feeling that we first need a good classification of the possible scenarios in order to be sure that whenever someone proposes an idea it can be made clear in which setting this idea is supposed to help. We shouldn't go into the details of SIP headers now. /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 13:11:36 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD8428C3C0; Fri, 22 Feb 2008 13:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF2Re66e2akC; Fri, 22 Feb 2008 13:11:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D559928C293; Fri, 22 Feb 2008 13:11:35 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328F93A6819 for ; Fri, 22 Feb 2008 13:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRyxDwQgywRV for ; Fri, 22 Feb 2008 13:11:33 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id B0FD63A6866 for ; Fri, 22 Feb 2008 13:11:32 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28135356; Fri, 22 Feb 2008 21:11:27 +0000 In-Reply-To: <8651E525-0D5B-4C50-9DE0-7698915EDDF1@cisco.com> References: <8651E525-0D5B-4C50-9DE0-7698915EDDF1@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <59B8FCE9-E5A8-4B19-947B-D031D209E0AC@voxeo.com> From: Dan York Date: Fri, 22 Feb 2008 16:11:24 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.753) Cc: rucus@ietf.org, Francois Audet Subject: Re: [Rucus] Chair for RUCUS BOF X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0594875438==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============0594875438== Content-Type: multipart/alternative; boundary=Apple-Mail-246--78298208 --Apple-Mail-246--78298208 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Great to hear and I'm very much looking forward to the session in Philadelphia! Dan On Feb 22, 2008, at 2:52 PM, Cullen Jennings wrote: > > I am very pleased to let folks know that Francois and Hannes have > agreed to run the RUCUS BOF and will be the co-chairs of the BOF. > > Thanks to everyone for all the work going into this > > Cullen > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-246--78298208 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Great to hear and I'm very much = looking forward to the session in Philadelphia!

Dan

= On Feb 22, 2008, at 2:52 PM, Cullen Jennings wrote:


I am = very pleased to let folks know that Francois and Hannes have =A0
agreed = to run the RUCUS BOF and will=A0 = be the co-chairs of the BOF.

Thanks to everyone for all the = work going into this
Cullen <RAI AD>


Rucus mailing list

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-246--78298208-- --===============0594875438== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============0594875438==-- From rucus-bounces@ietf.org Fri Feb 22 13:18:52 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5083A28C1D1; Fri, 22 Feb 2008 13:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.901 X-Spam-Level: * X-Spam-Status: No, score=1.901 tagged_above=-999 required=5 tests=[AWL=-2.662, BAYES_00=-2.599, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_VIAGRA=2.5, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNZO73+ykmr6; Fri, 22 Feb 2008 13:18:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741FC3A6866; Fri, 22 Feb 2008 13:18:51 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244A13A6866 for ; Fri, 22 Feb 2008 13:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-hJj2ADXk-v for ; Fri, 22 Feb 2008 13:18:50 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 359613A6819 for ; Fri, 22 Feb 2008 13:18:50 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id E104E4D605; Fri, 22 Feb 2008 22:18:44 +0100 (CET) Date: Fri, 22 Feb 2008 22:18:44 +0100 From: Otmar Lendl To: rucus@ietf.org Message-ID: <20080222211844.GC1983@bofh.priv.at> References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <47BEB721.8040305@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF53DB8D@mx1.office> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF53DB8D@mx1.office> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/22 13:02, Saverio Niccolini wrote: > > > Let's take an example: > > When Henning's host is compromised and a bot is using > > Henning's account to send me spam then I would contact > > Henning (by using various ways) to tell him that something is > > wrong with his PC/phone/etc. I would not tell my VoIP > > provider that there is something wrong with Henning's account. > > Typically, this will lead to more problems rather than less > > -- such as no communication to Columbia University anymore > > because my VoIP provider just blocks all calls from that domain. > > > > (Just to reflect my experience with email problems in the company....) > > You do not contact Henning directly to tell him that something > is wrong. You have to rely on your infrastructure to take the > necessary countermeasures otherwise it is the anarchy... No, not when strong identity is used. Just translate the scenario to email: when I receive a PGP-signed mail (using a trusted key) from a friend which contains a typical spam (V!ag_ra, 419, ...) then I'll phone him up to tell him that he has a security problem. > That is why exchanging reputation of identities (as perceived by > end-users or domains) is an important building block. Yes, it can be helpful to simplify the initial contact problem. Positive reputation is useful, negative one will just lead to the spitter getting a new account. > Such reputation system (one of the points of RFC 5039) can be built > using mechanisms like feedbacks: > http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 > and spam scores: > http://tools.ietf.org/html/draft-wing-sipping-spam-score-01 > of course there are privacy issues that apply (but this is > a problem of reputation systems as well) :-) Another trouble here is that if you want worldwide calling based on a reputation system, you also need a reputation system which is used worldwide and not a plethora of these. Who will be trusted to run it? /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri Feb 22 17:56:51 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C503A6B2D; Fri, 22 Feb 2008 17:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRLk1ELCvHRs; Fri, 22 Feb 2008 17:56:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C74933A6824; Fri, 22 Feb 2008 17:56:29 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431643A67B2 for ; Fri, 22 Feb 2008 17:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcA+zE3LsdNQ for ; Fri, 22 Feb 2008 17:56:26 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 5E7323A69B0 for ; Fri, 22 Feb 2008 17:52:27 -0800 (PST) Received: from [192.168.0.57] (pool-71-250-74-26.nwrknj.east.verizon.net [71.250.74.26]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m1N1qKRl017778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Feb 2008 20:52:21 -0500 (EST) Message-Id: From: Henning Schulzrinne To: Saverio Niccolini In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF53DBF3@mx1.office> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 20:52:37 -0500 References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> DEFANGED[1]:DEFANGED[4]:<42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu><47BEAEE3.4040701@gmx.net><113091BD57179D4491C19DA7E10CD69601B56 " " 39F@mx1.offi " " ce> <47BEB721.8040305@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF53DB8D@mx1.office> <47BEC2A8.50201@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF53DBF3@mx1.office> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: rucus@ietf.org Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On Feb 22, 2008, at 1:22 PM, Saverio Niccolini wrote: >>> You do not contact Henning directly to tell him that something is >>> wrong. You have to rely on your infrastructure to take the >> necessary >>> countermeasures otherwise it is the anarchy... >>> >> Why wouldn't I contact him directly? > > -1- you are saying that if people in the world receive 1.000.000 spam > calls then they should generate an equal number of calls to let the > other people know? I am sure there are more intelligent things to do > than that... You are mis-understanding Hannes case. He was addressing the case where the sender is authenticated and known to the callee, i.e., a friend. > > -2- have you ever heard of reflection attacks when reading about DoS, > what if the purpose of the compromised account is not only to deliver > you a telemarketing call but also to move people to bring down > Henning's phone by calling him back? > > I hope these two are enough to understand that what you > suggest is in principle NOT the solution... Please re-read the classification; you are talking about the 'random spewing' attack, in which case your concern is indeed valid. That attack is likely only stoppable by rate-limiting calls near the origin. > > Are you saying that a model with white lists for calls would be > more acceptable then? That my mother (even if she learnt how to use > the PC since I am living abroad just to stay in contact with me) > would configure her white list and switch its authorization policies > every time she wants to be contacted by unknown people? > Are you aware of how many people nowadays do not use properly > presence indicators? (even skilled people) > White list configuration is a problem, but it can be largely automated. For example, we have proposed that successful bidirectional email communication and certain types of secured web interactions can be used to populate white lists. This does mean that you'll have to use a lower-impact means to initially contact somebody. But that's pretty much how things work today, given that many phones are not listed in public directories. I admit that I much prefer people emailing me first, so that I can decide whether to give out my phone number. > I would say my mother would rely on the provider to filter the > vary bad calls on her behalf (using some sort of spam score and > reputation system) and if she receives a spam call every now and then > she would be able to press a button on her phone for "spam feedback" > > And of course, she has some authorization policies (but not the one: > receive call only from white list...) > > That is why the "white list" concept is not enough without the > "black list" concept. and I think it would be nonsense for RUCUS > to focus only on "white list" and related architecture > (remember that reputation is both "white" and "black"...) > For reasons others have mentioned, black lists are largely useless unless identities become extremely expensive and scarce. They are, however, useful to prevent the same compromised host from calling me again and again. (This is a well-known PSTN problem: Somehow, a fax machine gets hold of your voice number. The call fails, and then the fax machine dutifully redials once every 5 minutes. You either have to learn how to whistle like a modem, or you need a blacklist.) Henning _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Feb 23 02:22:21 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4AD3A6A35; Sat, 23 Feb 2008 02:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2V32cLr83Ji; Sat, 23 Feb 2008 02:22:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C04F3A6A28; Sat, 23 Feb 2008 02:22:20 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1503A69E7 for ; Sat, 23 Feb 2008 02:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBBdv+sIDsg5 for ; Sat, 23 Feb 2008 02:22:18 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 301833A6A34 for ; Sat, 23 Feb 2008 02:22:15 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 7E0C52C000357; Sat, 23 Feb 2008 11:22:10 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KngXyF1fLn+P; Sat, 23 Feb 2008 11:22:10 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 6AA6B2C000355; Sat, 23 Feb 2008 11:22:00 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 23 Feb 2008 11:20:12 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD69601B56458@mx1.office> In-Reply-To: <20080222205642.GB1983@bofh.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter Thread-Index: Ach1lbkAQH4UdAKJRx2JEySCjK2e5AAbvfRA References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com><47BEAEE3.4040701@gmx.net><113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office> <20080222205642.GB1983@bofh.priv.at> From: "Jan Seedorf" To: "Otmar Lendl" , Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear Otmar, > Reading the last 30 mails here on the list I have the feeling > that we first need a good classification of the possible > scenarios in order to be sure that whenever someone proposes > an idea it can be made clear in which setting this idea is > supposed to help. That is a very good point, I agree. Depending on the attack scenario (and there can be different ones as discussed on this list) and certain assumptions (e.g., attacker is using user credentials) we need to find out what architectural setting can help best. Differentiating between such scenarios would give us "a common ground" for discussion and help to avoid some confusion. > We shouldn't go into the details of SIP headers now. I agree. - Jan > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Otmar Lendl > Sent: Friday, February 22, 2008 9:57 PM > To: rucus@ietf.org > Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft > RUCUS charter > > On 2008/02/22 12:02, Jan Seedorf wrote: > > > > > I think we should put Henning's classification somewhere in our > > > documents. > > I also like Henning's classification because it narrows > down where the problem with botnets regarding SPIT is. > > Same here, Henning's classification is really helpful. > > Reading the last 30 mails here on the list I have the feeling > that we first need a good classification of the possible > scenarios in order to be sure that whenever someone proposes > an idea it can be made clear in which setting this idea is > supposed to help. > > We shouldn't go into the details of SIP headers now. > > /ol > -- > -=- Otmar Lendl -- ol@bofh.priv.at -=- > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Feb 23 04:19:14 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A3893A6A83; Sat, 23 Feb 2008 04:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.507 X-Spam-Level: X-Spam-Status: No, score=-0.507 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13abhepo5WNS; Sat, 23 Feb 2008 04:19:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC173A6A4B; Sat, 23 Feb 2008 04:19:13 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5276D3A6A4B for ; Sat, 23 Feb 2008 04:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsN47fp6xgWc for ; Sat, 23 Feb 2008 04:19:11 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 15E933A6A83 for ; Sat, 23 Feb 2008 04:19:11 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 585562C000357 for ; Sat, 23 Feb 2008 13:19:06 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTV8y2E8Totm for ; Sat, 23 Feb 2008 13:19:06 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 44AE72C000355 for ; Sat, 23 Feb 2008 13:19:01 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 23 Feb 2008 13:19:00 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DC03@mx1.office> In-Reply-To: <20080222211844.GC1983@bofh.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter Thread-Index: Ach1mJaOG0Lh/dKURWyO1/zNXMH+PQAfO8YA References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com><47BEB721.8040305@gmx.net><5F6519BF2DE0404D99B7C75607FF76FF53DB8D@mx1.office> <20080222211844.GC1983@bofh.priv.at> From: "Saverio Niccolini" To: Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > Another trouble here is that if you want worldwide calling > based on a reputation system, you also need a reputation > system which is used worldwide and not a plethora of these. > > Who will be trusted to run it? You can have reputation system run among a federations of providers. And if you are assuming there are strong identities, you are assuming you are using PKI then you must trust someone, the same someone can be used to provide the reputation system. Anyway I must admit that I was making confusions among scenarios. I agree that it is better to work on fixing scenarios and then analyze architectures and solutions. My only point is that I do not want to exclude any technical solution now that we are starting exploring. Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Feb 23 08:28:55 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7D23A6AA0; Sat, 23 Feb 2008 08:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcL1p3N7hl8v; Sat, 23 Feb 2008 08:28:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B243A6A9B; Sat, 23 Feb 2008 08:28:52 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD98B28C28E for ; Sat, 23 Feb 2008 08:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKWayPizKwAP for ; Sat, 23 Feb 2008 08:28:48 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 8521728C39B for ; Sat, 23 Feb 2008 08:27:47 -0800 (PST) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 7E2A44C5AD; Sat, 23 Feb 2008 17:27:41 +0100 (CET) Date: Sat, 23 Feb 2008 17:27:41 +0100 From: Otmar Lendl To: rucus@ietf.org Message-ID: <20080223162741.GD1983@bofh.priv.at> References: <20080222211844.GC1983@bofh.priv.at> <5F6519BF2DE0404D99B7C75607FF76FF53DC03@mx1.office> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF53DC03@mx1.office> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/02/23 13:02, Saverio Niccolini wrote: > > And if you are assuming there are strong identities, you > are assuming you are using PKI then you must trust someone, > the same someone can be used to provide the reputation > system. Sorry, but in order to run an effective and secure whitelist, no PKI is needed. A centralized PKI to sign keys is just needed if you want to base the whitelist on URIs and not on key-fingerprints. > I agree that it is better to work on fixing scenarios and then > analyze architectures and solutions. Ok, who writes the draft? > My only point is that I do not want to exclude any technical > solution now that we are starting exploring. That's a fair point. /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sun Feb 24 09:59:58 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4943A6B3E; Sun, 24 Feb 2008 09:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPmJZNwgWqJ5; Sun, 24 Feb 2008 09:59:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED483A6BF9; Sun, 24 Feb 2008 09:59:57 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33A53A6BF9 for ; Sun, 24 Feb 2008 09:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqv+dWH59CVK for ; Sun, 24 Feb 2008 09:59:56 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7F9083A6A7C for ; Sun, 24 Feb 2008 09:59:55 -0800 (PST) Received: (qmail invoked by alias); 24 Feb 2008 17:59:48 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp054) with SMTP; 24 Feb 2008 18:59:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/muNB7g7Dm2EJD3rdeyozOSMK5S/kH1eGL4Ufkwa WV3IqCPvMTKVQK Message-ID: <47C1B090.7050605@gmx.net> Date: Sun, 24 Feb 2008 19:59:44 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Charzinski, Joachim (NSN - DE/Muenich)" References: <3A86FA4E-6D4A-43FE-B380-6676CD4BCD90@voxeo.com> <42B56C6A683EBA4581C01CB49A914CA70E6EA261@MAILFAXSRV.gfimalta.com><909E8DC8-CB3A-478D-995F-94A4B3656D8D@cs.columbia.edu><47BEAEE3.4040701@gmx.net><113091BD57179D4491C19DA7E10CD69601B5639F@mx1.office><47BEB721.8040305@gmx.net><198A10EC585EC74687BCA414E2A5971802093DFC@MCHP7RDA.ww002.siemens.net> <47BEC03A.8070009@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org, Jan Seedorf , Juergen Quittek Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Interesting; I have never been able to configure white lists even I = thought I sometimes would have liked to do so The user interfaces with some of these phones is just horrible; without = changing this we will never see widespread usage of white lists. Charzinski, Joachim (NSN - DE/Muenich) wrote: > Hi Hannes, > > = >> For the PSTN there are obviously no white lists either >> >> = > not quite. A lot of PSTN switches should have white lists = > already, it is just a question = > - if the operators allow user administration and > - if the users really appreciate using a voice interface = > or a separate web login to administer those lists > > Best regards > > Joachim. > = > ---------------------------------------------------------- > Nokia Siemens Networks > > Joachim Charzinski > Principal Innovator > > Visitor address: Machtlfinger Str. 1 / D-81379 Muenchen / Germany > Postal address: D-80240 Muenchen / Germany > > Tel: +49 89 722 46803 / Joachim.Charzinski@nsn.com / http://www.nokiasiem= ensnetworks.com/global/ = > > Think before you print > > Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft: M=FCnchen /= Registered office: Munich - Registergericht: M=FCnchen / Commercial regist= ry: Munich, HRA 88537 - WEEE-Reg.-Nr.: DE 52984304 - Pers=F6nlich haftende = Gesellschafterin / General Partner: Nokia Siemens Networks Management GmbH = - Gesch=E4ftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer -= Sitz der Gesellschaft: M=FCnchen / Registered office: Munich - Registerger= icht: M=FCnchen / Commercial registry: Munich, HRB 163416 > = _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 25 19:02:55 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3113A6BBE; Mon, 25 Feb 2008 19:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krxeVkMRyVOK; Mon, 25 Feb 2008 19:02:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45BE73A6B56; Mon, 25 Feb 2008 19:02:54 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA983A682A for ; Mon, 25 Feb 2008 19:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIx74ymwQwXB for ; Mon, 25 Feb 2008 19:02:52 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5B6993A6AC9 for ; Mon, 25 Feb 2008 19:02:44 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Feb 2008 19:02:38 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1Q32cE7021921 for ; Mon, 25 Feb 2008 19:02:38 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m1Q32WJH006268 for ; Tue, 26 Feb 2008 03:02:38 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 19:02:36 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 19:02:36 -0800 Message-ID: <47C38140.7000604@cisco.com> Date: Mon, 25 Feb 2008 22:02:24 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: rucus@ietf.org X-OriginalArrivalTime: 26 Feb 2008 03:02:36.0537 (UTC) FILETIME=[0A339E90:01C87824] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1093; t=1203994958; x=1204858958; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-york-sipping-spit-similar ity-scenarios-00 |Sender:=20; bh=NQyz9EU1Zmt4Tt/2pHv8P6iEBrEOIwr8+2WMC97alOg=; b=tD6qwPedlWbb6i0+P9j0HzcyJqoZM3xVpqj752L6hGBZAOLqGFGF1a30aM IbP3GavxGDIyzic3QWdt11i5N1gIFUUTLgQZuKWgJnEwM/Oks3Z6Es80S/Qy ffNGTFuaIMVBvlh7LDyo5Pr7ZHop49Tm7V4aE7GGW2YsJy0enuwz0=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Rucus] comments on draft-york-sipping-spit-similarity-scenarios-00 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Thanks for writing this up, Dan. Couple of comments. In many of the use cases you describe there is probably some aspect of the system that allows these cases to be differentiated from SPIT. For example, for emergency traffic, the fact that the requests originated from the emergency notification server tells its downstream proxy that this is not an attack. Similarly, the domain that runs the emergency notification service would probably tell its downstream service provider that this can happen, and they can agree upon ways to separate this traffic out. This doesn't work in all cases but in some. Also, using rfc4474 for these kinds of sources can help; since the set of such sources is small you can use whitelisting in downstream proxies to deal with it. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Feb 25 19:08:51 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2090E3A6B56; Mon, 25 Feb 2008 19:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.273 X-Spam-Level: X-Spam-Status: No, score=-1.273 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xia+7-1AtSCf; Mon, 25 Feb 2008 19:08:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6571A3A6ACE; Mon, 25 Feb 2008 19:08:50 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA723A6ACE for ; Mon, 25 Feb 2008 19:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhyM1hzxDJG7 for ; Mon, 25 Feb 2008 19:08:48 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 310523A69A4 for ; Mon, 25 Feb 2008 19:08:48 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2008 19:08:42 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1Q38gYI017554 for ; Mon, 25 Feb 2008 19:08:42 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1Q38gp4023121 for ; Tue, 26 Feb 2008 03:08:42 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 19:08:42 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 19:08:41 -0800 Message-ID: <47C382AF.7060109@cisco.com> Date: Mon, 25 Feb 2008 22:08:31 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: rucus@ietf.org X-OriginalArrivalTime: 26 Feb 2008 03:08:42.0084 (UTC) FILETIME=[E415AA40:01C87824] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1333; t=1203995322; x=1204859322; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-niccolini-sipping-spam-fe edback-00 |Sender:=20; bh=MSBX/j76gMMKKPuEPTperL40HD0Nx55UMY/GUqsnePU=; b=slci2goCTOTbf9Lb+tXsqGd18ckU70M9g47u3XWvgmKzToByzxQRln0JBa 7mm+yXAody1+MPs2xIO7lGWWfOyKHWlty+UPvR62BdVl7j3yO8arbhjX3lgc 9+s7MdSABy; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Thanks for writing this, its a good topic to discuss. One thing that wasn't clear; what is the benefit of signaling something as spam to my proxy, as opposed to just putting the sender on a black list. We have mechanisms defined already for that, for example. I suspect its around sharing of the spam classification with other users in the domain. Its worth discussing this. Seems easier if you just send the entire sip message as content rather than picking apart pieces of it. The mechanism is clearly intended to be between a UA and a proxy in its own domain; however I didn't find that stated till much deeper in the document. This should be clear up front. In terms of specific protocols, I think SUB/NOT is a very poor choice. The proxy will require a subscription to EVERY UA, and the events will be infrequent. This means a lot of overhead for little data. I think you are much better off with an asynchronous push, either PUBLISH or even non-sip. Maybe a REST interface or something. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 00:11:00 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CCB53A6C7B; Tue, 26 Feb 2008 00:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6L8yFob0QF0; Tue, 26 Feb 2008 00:10:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FD53A6BF2; Tue, 26 Feb 2008 00:10:59 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0633A6B79 for ; Tue, 26 Feb 2008 00:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2uf00Oik7aA for ; Tue, 26 Feb 2008 00:10:58 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B10C23A6C28 for ; Tue, 26 Feb 2008 00:10:57 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2008 08:10:50 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp049) with SMTP; 26 Feb 2008 09:10:50 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/U6B4Icf7UlClcLWcBxCFYKE9qYub1ssgpaBzKzH gbbXgspTY18ta8 Message-ID: <47C3C986.3020406@gmx.net> Date: Tue, 26 Feb 2008 10:10:46 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jonathan Rosenberg References: <47C38140.7000604@cisco.com> In-Reply-To: <47C38140.7000604@cisco.com> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] comments on draft-york-sipping-spit-similarity-scenarios-00 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Jonathan, I think it is not that easy for 2 reasons: First, we don't know yet how an IP-based early warning architecture would look like. Second, your approach only works if you consider a deployment similar to the telephone network today. It does not work in an IP-based network with roaming users where every emergency services operator would have to establish a relationship with every other VoIP provider.... I do, however, agree that these special cases need to be dealt with even with mechanisms like white lists somehow. They are not only relevant for mechanisms that use some of these "statistical learning techniques". Ciao Hannes Jonathan Rosenberg wrote: > Thanks for writing this up, Dan. > > Couple of comments. In many of the use cases you describe there is > probably some aspect of the system that allows these cases to be > differentiated from SPIT. For example, for emergency traffic, the fact > that the requests originated from the emergency notification server > tells its downstream proxy that this is not an attack. Similarly, the > domain that runs the emergency notification service would probably tell > its downstream service provider that this can happen, and they can agree > upon ways to separate this traffic out. This doesn't work in all cases > but in some. > > Also, using rfc4474 for these kinds of sources can help; since the set > of such sources is small you can use whitelisting in downstream proxies > to deal with it. > > Thanks, > Jonathan R. > > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 00:16:31 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD38D3A6CA8; Tue, 26 Feb 2008 00:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypYX1RBmoZ69; Tue, 26 Feb 2008 00:16:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7F63A6C39; Tue, 26 Feb 2008 00:16:30 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADFC3A683D for ; Tue, 26 Feb 2008 00:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IFVlun8Gdeo for ; Tue, 26 Feb 2008 00:16:15 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 15C423A6BF2 for ; Tue, 26 Feb 2008 00:16:14 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2008 08:16:08 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp028) with SMTP; 26 Feb 2008 09:16:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18F2WZNR2cFMTCwjKVyIQmoVZ2KFafNAuZgOb6gem MjKzLbbxoaRvmN Message-ID: <47C3CAC4.6030604@gmx.net> Date: Tue, 26 Feb 2008 10:16:04 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jonathan Rosenberg References: <47C382AF.7060109@cisco.com> In-Reply-To: <47C382AF.7060109@cisco.com> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Jonathan, thanks for your feedback. You are right that this mechanism does not make a lot of sense if you consider an architecture that uses authorization policies and whitelists in particular. It makes some sense when you consider these statistical learning techniques that require "good" and "bad" examples to learn. This is obviously a -00 draft and I believe we should end up with this work is more something along the lines of Peter's work http://www.xmpp.org/extensions/inbox/error-abuse.html where there is communication between proxies rather than between the end host and the proxy. Ciao Hannes Jonathan Rosenberg wrote: > Thanks for writing this, its a good topic to discuss. > > One thing that wasn't clear; what is the benefit of signaling something > as spam to my proxy, as opposed to just putting the sender on a black > list. We have mechanisms defined already for that, for example. I > suspect its around sharing of the spam classification with other users > in the domain. Its worth discussing this. > > Seems easier if you just send the entire sip message as content rather > than picking apart pieces of it. > > The mechanism is clearly intended to be between a UA and a proxy in its > own domain; however I didn't find that stated till much deeper in the > document. This should be clear up front. > > In terms of specific protocols, I think SUB/NOT is a very poor choice. > The proxy will require a subscription to EVERY UA, and the events will > be infrequent. This means a lot of overhead for little data. I think you > are much better off with an asynchronous push, either PUBLISH or even > non-sip. Maybe a REST interface or something. > > Thanks, > Jonathan R. > > > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 00:48:14 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C967A28C3C4; Tue, 26 Feb 2008 00:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.512 X-Spam-Level: X-Spam-Status: No, score=-0.512 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqcmV1THh-YJ; Tue, 26 Feb 2008 00:48:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D599128C22D; Tue, 26 Feb 2008 00:48:12 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32B63A6C1C for ; Tue, 26 Feb 2008 00:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOnu3QmMi4TR for ; Tue, 26 Feb 2008 00:48:10 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3A1713A6BE8 for ; Tue, 26 Feb 2008 00:48:10 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 284232C002B4A for ; Tue, 26 Feb 2008 09:48:04 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT3sMbmj329E for ; Tue, 26 Feb 2008 09:48:04 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 0D9C42C000355 for ; Tue, 26 Feb 2008 09:47:59 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 09:47:56 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DD85@mx1.office> In-Reply-To: <47C3CAC4.6030604@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00 Thread-Index: Ach4T/MbKKZoGkcHSaCh+I0VXvGMMAAAlnoQ References: <47C382AF.7060109@cisco.com> <47C3CAC4.6030604@gmx.net> From: "Saverio Niccolini" To: Subject: Re: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes, > You are right that this mechanism does not make a lot of > sense if you consider an architecture that uses authorization > policies and whitelists in particular. Wrong... In the case a spammer will get through the "white list and authorization policies" framework then you have an additional weapon to just report abuse which is automatic and not manual (call my friend and tell him). Telling it to your proxy could be a way of updating your authorization policies (maybe even update your personal black list at the domain) and to share info on the caller with the domain (to get to a domain-wide reputation system, with all pros and cons) > It makes some sense when you consider these statistical > learning techniques that require "good" and "bad" examples to learn. Again wrong... The feedback can be also linked to "binary" decisions like: if I send a bad feedback for a caller "deny him from calling me for today" or "next time challenge him with a CAPTCHA" > This is obviously a -00 draft and I believe we should end up > with this work is more something along the lines of Peter's work > > http://www.xmpp.org/extensions/inbox/error-abuse.html > where there is communication between proxies rather than > between the end host and the proxy. I agree there must be many updates to the draft (proxy to proxy communication is one of them) and I will take into account the valuable point of Jonathan when submitting the next version. Saverio > > Ciao > Hannes > > > > Jonathan Rosenberg wrote: > > Thanks for writing this, its a good topic to discuss. > > > > One thing that wasn't clear; what is the benefit of signaling > > something as spam to my proxy, as opposed to just putting > the sender > > on a black list. We have mechanisms defined already for that, for > > example. I suspect its around sharing of the spam > classification with > > other users in the domain. Its worth discussing this. > > > > Seems easier if you just send the entire sip message as > content rather > > than picking apart pieces of it. > > > > The mechanism is clearly intended to be between a UA and a proxy in > > its own domain; however I didn't find that stated till much > deeper in > > the document. This should be clear up front. > > > > In terms of specific protocols, I think SUB/NOT is a very > poor choice. > > The proxy will require a subscription to EVERY UA, and the > events will > > be infrequent. This means a lot of overhead for little > data. I think > > you are much better off with an asynchronous push, either > PUBLISH or > > even non-sip. Maybe a REST interface or something. > > > > Thanks, > > Jonathan R. > > > > > > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283201 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 01:21:46 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C283A6BC4; Tue, 26 Feb 2008 01:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsuKspo03CdH; Tue, 26 Feb 2008 01:21:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48AA43A6957; Tue, 26 Feb 2008 01:21:42 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9543A6984 for ; Tue, 26 Feb 2008 01:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vc3VnqmU+ssE for ; Tue, 26 Feb 2008 01:21:40 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 24BAB3A6862 for ; Tue, 26 Feb 2008 01:21:36 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D9BAC2C002B4A; Tue, 26 Feb 2008 10:21:29 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyePlwRV5kH9; Tue, 26 Feb 2008 10:21:29 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id C63C92C000355; Tue, 26 Feb 2008 10:21:19 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 10:21:17 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DD92@mx1.office> In-Reply-To: <47C382AF.7060109@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00 Thread-Index: Ach4JPq1vKlCIiArS1Gdhn1GnP7c8QAMyBxw References: <47C382AF.7060109@cisco.com> From: "Martin Stiemerling" To: "Jonathan Rosenberg" , Subject: Re: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Jonathan, > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Jonathan Rosenberg > Sent: Tuesday, February 26, 2008 4:09 AM > To: rucus@ietf.org > Subject: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00 > > Thanks for writing this, its a good topic to discuss. > > One thing that wasn't clear; what is the benefit of signaling > something as spam to my proxy, as opposed to just putting the > sender on a black list. We have mechanisms defined already > for that, for example. I suspect its around sharing of the > spam classification with other users in the domain. Its worth > discussing this. Putting senders on a black list might be good for a subset of users but not others. This also depends on how those blacklists are managed. Therefore, the approach to give feedback from users to a spam system, i.e., sharing knowledge among users. > > Seems easier if you just send the entire sip message as > content rather than picking apart pieces of it. > > The mechanism is clearly intended to be between a UA and a > proxy in its own domain; however I didn't find that stated > till much deeper in the document. This should be clear up front. > > In terms of specific protocols, I think SUB/NOT is a very > poor choice. > The proxy will require a subscription to EVERY UA, and the > events will be infrequent. This means a lot of overhead for > little data. I think you are much better off with an > asynchronous push, either PUBLISH or even non-sip. Maybe a > REST interface or something. We're open to discuss the protocol choice for doing this. The SUB/NOT approach is a first attempt to integrate this with SIP and is open for further discussions. Martin stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 01:27:29 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83683A6C1C; Tue, 26 Feb 2008 01:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.588 X-Spam-Level: X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7CCwhppEGbl; Tue, 26 Feb 2008 01:27:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0593A6957; Tue, 26 Feb 2008 01:27:27 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48CA43A6957 for ; Tue, 26 Feb 2008 01:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owCPzEojj84U for ; Tue, 26 Feb 2008 01:27:24 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2F7D83A698C for ; Tue, 26 Feb 2008 01:26:49 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 113D02C009E8F; Tue, 26 Feb 2008 10:26:43 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82V41S0reqFN; Tue, 26 Feb 2008 10:26:42 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id E5FB82C000355; Tue, 26 Feb 2008 10:26:27 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 10:26:26 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DD94@mx1.office> In-Reply-To: <47C3CAC4.6030604@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00 Thread-Index: Ach4T/M6EdkH2cRUQt217W5cChSoeQACRKcQ References: <47C382AF.7060109@cisco.com> <47C3CAC4.6030604@gmx.net> From: "Martin Stiemerling" To: , "Jonathan Rosenberg" Cc: rucus@ietf.org Subject: Re: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Hannes, > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Tuesday, February 26, 2008 9:16 AM > To: Jonathan Rosenberg > Cc: rucus@ietf.org > Subject: Re: [Rucus] comments on > draft-niccolini-sipping-spam-feedback-00 > > Hi Jonathan, > > thanks for your feedback. > > You are right that this mechanism does not make a lot of > sense if you consider an architecture that uses authorization > policies and whitelists in particular. Not fully true. I would call authorization policies and whitelists as the first line of defense, but not the ultimate. Authorization policies and whitelists are also known from email spam mitigation. However, we all know that they help but they are not the overall cure for the spam problem. > It makes some sense when you consider these statistical > learning techniques that require "good" and "bad" examples to learn. > > This is obviously a -00 draft and I believe we should end up > with this work is more something along the lines of Peter's work > > http://www.xmpp.org/extensions/inbox/error-abuse.html Yet another early work at a different venue. > where there is communication between proxies rather than > between the end host and the proxy. That is another area of interest which does not preclude what we are talking about Martin > > Ciao > Hannes > > > > Jonathan Rosenberg wrote: > > Thanks for writing this, its a good topic to discuss. > > > > One thing that wasn't clear; what is the benefit of signaling > > something as spam to my proxy, as opposed to just putting > the sender > > on a black list. We have mechanisms defined already for that, for > > example. I suspect its around sharing of the spam > classification with > > other users in the domain. Its worth discussing this. > > > > Seems easier if you just send the entire sip message as > content rather > > than picking apart pieces of it. > > > > The mechanism is clearly intended to be between a UA and a proxy in > > its own domain; however I didn't find that stated till much > deeper in > > the document. This should be clear up front. > > > > In terms of specific protocols, I think SUB/NOT is a very > poor choice. > > The proxy will require a subscription to EVERY UA, and the > events will > > be infrequent. This means a lot of overhead for little > data. I think > > you are much better off with an asynchronous push, either > PUBLISH or > > even non-sip. Maybe a REST interface or something. > > > > Thanks, > > Jonathan R. > > > > > > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 03:08:10 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA1328C24C; Tue, 26 Feb 2008 03:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.558 X-Spam-Level: X-Spam-Status: No, score=-0.558 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHdZPU0KQHiF; Tue, 26 Feb 2008 03:08:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F3C28C1B7; Tue, 26 Feb 2008 03:08:09 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F4A3A6B77 for ; Tue, 26 Feb 2008 03:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLzRBcB4WhrE for ; Tue, 26 Feb 2008 03:08:06 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D9D743A6BCA for ; Tue, 26 Feb 2008 03:08:05 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2008 11:07:58 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp001) with SMTP; 26 Feb 2008 12:07:58 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/jNAlVxUjj+NQ3+l24hxOPw/nGUFiw2dA+nGFbAY q4j56pIbWbf9I5 Message-ID: <47C3F313.5000605@gmx.net> Date: Tue, 26 Feb 2008 13:08:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Saverio Niccolini References: <47C382AF.7060109@cisco.com> <47C3CAC4.6030604@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF53DD85@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF53DD85@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Saverio, being wrong twice could be a post-submission deadline syndrome... Some comments inline: Saverio Niccolini wrote: > Hannes, > > >> You are right that this mechanism does not make a lot of >> sense if you consider an architecture that uses authorization >> policies and whitelists in particular. >> > > Wrong... > In the case a spammer will get through the "white list and authorization > policies" framework then you have an additional weapon to just report abuse > which is automatic and not manual (call my friend and tell him). > Hmmm. Might be. Certainly not my personal #1 choice. > Telling it to your proxy could be a way of updating your authorization > policies (maybe even update your personal black list at the domain) > and to share info on the caller with the domain (to get to a domain-wide > reputation system, with all pros and cons) > > regarding the updating of the authorization policies: but then this would be another mechanism for updating policies in additional to the already standardized and already implemented way of doing it. >> It makes some sense when you consider these statistical >> learning techniques that require "good" and "bad" examples to learn. >> > > Again wrong... > The feedback can be also linked to "binary" decisions like: > if I send a bad feedback for a caller "deny him from calling me > for today" or "next time challenge him with a CAPTCHA" > But this would be another way of modifying policies in addition to XCAP. > >> This is obviously a -00 draft and I believe we should end up >> with this work is more something along the lines of Peter's work >> >> http://www.xmpp.org/extensions/inbox/error-abuse.html >> where there is communication between proxies rather than >> between the end host and the proxy. >> > > I agree there must be many updates to the draft (proxy to proxy > communication is one of them) and I will take into account > the valuable point of Jonathan when submitting the next version. > > Ciao Hannes > Saverio > > >> Ciao >> Hannes >> >> >> >> Jonathan Rosenberg wrote: >> >>> Thanks for writing this, its a good topic to discuss. >>> >>> One thing that wasn't clear; what is the benefit of signaling >>> something as spam to my proxy, as opposed to just putting >>> >> the sender >> >>> on a black list. We have mechanisms defined already for that, for >>> example. I suspect its around sharing of the spam >>> >> classification with >> >>> other users in the domain. Its worth discussing this. >>> >>> Seems easier if you just send the entire sip message as >>> >> content rather >> >>> than picking apart pieces of it. >>> >>> The mechanism is clearly intended to be between a UA and a proxy in >>> its own domain; however I didn't find that stated till much >>> >> deeper in >> >>> the document. This should be clear up front. >>> >>> In terms of specific protocols, I think SUB/NOT is a very >>> >> poor choice. >> >>> The proxy will require a subscription to EVERY UA, and the >>> >> events will >> >>> be infrequent. This means a lot of overhead for little >>> >> data. I think >> >>> you are much better off with an asynchronous push, either >>> >> PUBLISH or >> >>> even non-sip. Maybe a REST interface or something. >>> >>> Thanks, >>> Jonathan R. >>> >>> >>> >>> >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> http://www.ietf.org/mailman/listinfo/rucus >> >> > > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 283201 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 03:13:46 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A29728C0E4; Tue, 26 Feb 2008 03:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY2kE9FEHR3P; Tue, 26 Feb 2008 03:13:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C963A6C25; Tue, 26 Feb 2008 03:13:43 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5833A692D for ; Tue, 26 Feb 2008 03:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXKKWCf8EwNW for ; Tue, 26 Feb 2008 03:13:41 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5FA463A68B1 for ; Tue, 26 Feb 2008 03:13:40 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2008 11:13:34 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp036) with SMTP; 26 Feb 2008 12:13:34 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/q3X4ZVfbqnWXIx2pdKyMJfSeiLhVAZ8CrEyzxRU Npj0Y2zBb6Yks1 Message-ID: <47C3F463.7060505@gmx.net> Date: Tue, 26 Feb 2008 13:13:39 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: rucus BoF X-Y-GMX-Trusted: 0 Subject: [Rucus] [Fwd: I-D Action:draft-lendl-speermint-background-01.txt] X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org An interesting document from Otmar. I missed the -00 version but this document relates to some of the comments Otmar made on the list, in particular the aspect that we do not see SPIT today primarily because we do not have too much VoIP peering today. -------- Original Message -------- Subject: I-D Action:draft-lendl-speermint-background-01.txt Date: Mon, 25 Feb 2008 13:15:02 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : VoIP Peering: Background and Assumptions Author(s) : O. Lendl Filename : draft-lendl-speermint-background-01.txt Pages : 15 Date : 2008-02-25 This documents provides background for the work on VoIP peering and tries to provide guidance on what kind of work is needed to facilitate widespread SIP-based peering of telephony networks. It is intended to spur discussion on the work about peering and should also serve as input to the ongoing discussions on reducing Spam for Internet Telephony (SPIT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-speermint-background-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lendl-speermint-background-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lendl-speermint-background-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 04:35:27 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6763A6D07; Tue, 26 Feb 2008 04:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.562 X-Spam-Level: X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzJBcZtyupyd; Tue, 26 Feb 2008 04:35:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA8653A6B26; Tue, 26 Feb 2008 04:35:26 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E153A6B8B for ; Tue, 26 Feb 2008 04:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKJb5jjbKque for ; Tue, 26 Feb 2008 04:35:25 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 00A693A6BA3 for ; Tue, 26 Feb 2008 04:35:24 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2008 12:35:17 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp020) with SMTP; 26 Feb 2008 13:35:17 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Uzv9p6CQUhrZ191fAVk95O0hxaaN2X0wTWh+PGB 2TgLf26+ya43WF Message-ID: <47C40782.6090907@gmx.net> Date: Tue, 26 Feb 2008 14:35:14 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: rucus BoF X-Y-GMX-Trusted: 0 Subject: [Rucus] RUCUS AGENDA (Proposal) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Here is the agenda proposal: http://www3.ietf.org/proceedings/08mar/agenda/rucus.txt Feedback welcome (I am still thinking about Juergens' idea to move the RFC5111 presentation to the beginning). _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 05:05:24 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8EED28C2DD; Tue, 26 Feb 2008 05:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.068 X-Spam-Level: * X-Spam-Status: No, score=1.068 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FROM_EXCESS_BASE64=1.456, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_25=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O5YwMRnHL2p; Tue, 26 Feb 2008 05:05:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEF528C265; Tue, 26 Feb 2008 05:05:19 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0FE428C276 for ; Tue, 26 Feb 2008 05:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXvxeKbI1TZn for ; Tue, 26 Feb 2008 05:05:17 -0800 (PST) Received: from smtp01.bis.na.blackberry.com (smtp01.bis.na.blackberry.com [216.9.248.48]) by core3.amsl.com (Postfix) with ESMTP id D93F228C265 for ; Tue, 26 Feb 2008 05:05:16 -0800 (PST) Received: from bxe134.bisx.prod.on.blackberry (bxe134.bisx.prod.on.blackberry [172.20.225.163]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id m1QCthgT014239; Tue, 26 Feb 2008 13:05:08 GMT X-rim-org-msg-ref-id: 1732796407 Message-ID: <1732796407-1204031108-cardhu_decombobulator_blackberry.rim.net-561282249-@bxe134.bisx.prod.on.blackberry> X-Priority: Normal References: <47C40782.6090907@gmx.net> In-Reply-To: <47C40782.6090907@gmx.net> Sensitivity: Normal Importance: Normal To: "Hannes Tschofenig" , "rucus BoF" From: "=?utf-8?B?RGFuIFlvcms=?=" Date: Tue, 26 Feb 2008 13:05:40 +0000 MIME-Version: 1.0 Subject: Re: [Rucus] RUCUS AGENDA (Proposal) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dyork@voxeo.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes, I will second Juergen's suggestion to move the RFC 5111 preso earlier. I would suggest it first, partly so that we can all get on the same page with regard to the ultimate goal of the BOF and also so that we can then focus on the subject of the session. Is Henning going to be covering your architecture draft? Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com -----Original Message----- From: Hannes Tschofenig Date: Tue, 26 Feb 2008 14:35:14 To:rucus BoF Subject: [Rucus] RUCUS AGENDA (Proposal) Here is the agenda proposal: http://www3.ietf.org/proceedings/08mar/agenda/rucus.txt Feedback welcome (I am still thinking about Juergens' idea to move the RFC5111 presentation to the beginning). _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 05:06:46 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5892128C450; Tue, 26 Feb 2008 05:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.562 X-Spam-Level: X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8++0+F5bits; Tue, 26 Feb 2008 05:06:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37CF28C2FA; Tue, 26 Feb 2008 05:06:43 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2128328C2C3 for ; Tue, 26 Feb 2008 05:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxV30r4o-acn for ; Tue, 26 Feb 2008 05:06:42 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C0F3D28C292 for ; Tue, 26 Feb 2008 05:06:41 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2008 13:06:35 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp041) with SMTP; 26 Feb 2008 14:06:35 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX196LDM2tnx6IOp4/7VKtm8DW0mHAHiT8hHeiYdmwy aI8BT3DCcQEDFK Message-ID: <47C40ED4.2000408@gmx.net> Date: Tue, 26 Feb 2008 15:06:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dyork@voxeo.com References: <47C40782.6090907@gmx.net> <1732796407-1204031108-cardhu_decombobulator_blackberry.rim.net-561282249-@bxe134.bisx.prod.on.blackberry> In-Reply-To: <1732796407-1204031108-cardhu_decombobulator_blackberry.rim.net-561282249-@bxe134.bisx.prod.on.blackberry> X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] RUCUS AGENDA (Proposal) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Henning is going to cover different architectural choices. Since Peter Saint-Andre is not able to attend this IETF meeting he will most likely (unless I find another way) also speak about the XMPP architecture for dealing with unwanted communication. Ciao Hannes Dan York wrote: > Hannes, > > I will second Juergen's suggestion to move the RFC 5111 preso earlier. I would suggest it first, partly so that we can all get on the same page with regard to the ultimate goal of the BOF and also so that we can then focus on the subject of the session. > > Is Henning going to be covering your architecture draft? > > Dan > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 05:09:17 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365D728C2FA; Tue, 26 Feb 2008 05:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZTXmjq1H9L1; Tue, 26 Feb 2008 05:09:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6167428C234; Tue, 26 Feb 2008 05:09:16 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96CA28C2C9 for ; Tue, 26 Feb 2008 05:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDOnrfZPnaJ8 for ; Tue, 26 Feb 2008 05:09:13 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C7CA23A6D07 for ; Tue, 26 Feb 2008 05:09:13 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 9A7492C009E8D for ; Tue, 26 Feb 2008 14:09:07 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ApdpEdupB3h for ; Tue, 26 Feb 2008 14:09:07 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 8A1492C000355 for ; Tue, 26 Feb 2008 14:09:02 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 14:09:02 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DDF2@mx1.office> In-Reply-To: <47C40782.6090907@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] RUCUS AGENDA (Proposal) Thread-Index: Ach4dB+WmQqU49/yToCnQ1VRNR63jQABB7tQ References: <47C40782.6090907@gmx.net> From: "Saverio Niccolini" To: "rucus BoF" Subject: Re: [Rucus] RUCUS AGENDA (Proposal) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes, > Here is the agenda proposal: > http://www3.ietf.org/proceedings/08mar/agenda/rucus.txt > > Feedback welcome -- I would not use the term SPIT near XMPP, SPIT acronym normally stands for SPam over Internet Telephony and XMPP is not traditionally associated with IP Telephony I would say... > (I am still thinking about Juergens' idea to move the RFC5111 > presentation to the beginning). -- I would really like to see this at the beginning, RFC 5111 is so new that people needs to know what we are talking about before going to the core of the discussion (we had this discussion already over the mailing list) Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 06:07:31 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C90E3A6C70; Tue, 26 Feb 2008 06:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3qtRybAJJ9I; Tue, 26 Feb 2008 06:07:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB1D28C2F8; Tue, 26 Feb 2008 06:07:27 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3FD28C2E4 for ; Tue, 26 Feb 2008 06:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kizgZxzfF3xN for ; Tue, 26 Feb 2008 06:07:23 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 58ECD3A6C74 for ; Tue, 26 Feb 2008 06:06:51 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 659522C009E8E; Tue, 26 Feb 2008 15:06:44 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z99iRQH1KQy; Tue, 26 Feb 2008 15:06:44 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 4E6522C002B4A; Tue, 26 Feb 2008 15:06:34 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 15:06:32 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DE0F@mx1.office> In-Reply-To: <47C40782.6090907@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] RUCUS AGENDA (Proposal) Thread-Index: Ach4dB+1PfjDv+TVQMC9WSPjwdlgcAADGZHQ References: <47C40782.6090907@gmx.net> From: "Martin Stiemerling" To: , "rucus BoF" Subject: Re: [Rucus] RUCUS AGENDA (Proposal) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Tuesday, February 26, 2008 1:35 PM > To: rucus BoF > Subject: [Rucus] RUCUS AGENDA (Proposal) > > Here is the agenda proposal: > http://www3.ietf.org/proceedings/08mar/agenda/rucus.txt > > Feedback welcome > > (I am still thinking about Juergens' idea to move the RFC5111 > presentation to the beginning). Again wrong! ;) It was me arguing to shift the RFC5111 presentation to the front. I would be in favour of doing this in the beginning, as this is part of the BoF setting. I.e., this can influence the discussions. Martin stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 08:20:11 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597AC3A6D49; Tue, 26 Feb 2008 08:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kMSSGp4mCXC; Tue, 26 Feb 2008 08:20:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790743A6B8B; Tue, 26 Feb 2008 08:20:07 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87B33A6CC9 for ; Tue, 26 Feb 2008 08:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7BdVJOM1bc5 for ; Tue, 26 Feb 2008 08:20:00 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C8BB43A6CBA for ; Tue, 26 Feb 2008 08:19:59 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2008 16:19:52 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.5]) [91.154.103.163] by mail.gmx.net (mp004) with SMTP; 26 Feb 2008 17:19:52 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX194YBN9JxB44N0jUgF+dFCHmui7DDE40RL9fsQf4r QtASUzUUdYFJAq Message-ID: <47C43C1F.5020406@gmx.net> Date: Tue, 26 Feb 2008 18:19:43 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Martin Stiemerling References: <47C40782.6090907@gmx.net> <5F6519BF2DE0404D99B7C75607FF76FF53DE0F@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF53DE0F@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] RUCUS AGENDA (Proposal) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Martin, >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >> On Behalf Of Hannes Tschofenig >> Sent: Tuesday, February 26, 2008 1:35 PM >> To: rucus BoF >> Subject: [Rucus] RUCUS AGENDA (Proposal) >> >> Here is the agenda proposal: >> http://www3.ietf.org/proceedings/08mar/agenda/rucus.txt >> >> Feedback welcome >> >> (I am still thinking about Juergens' idea to move the RFC5111 >> presentation to the beginning). >> > > Again wrong! ;) > It was me arguing to shift the RFC5111 presentation to the front. > > That's what I was saying. > I would be in favour of doing this in the beginning, as this is part of the BoF setting. I.e., this can influence the discussions. > ... on the other hand this belongs very much into the topic of charter discussions. Typically, if things don't go too well there isn't a need to discuss the charter either. But I don't want to be pessimistic. Ciao Hannes > Martin > > > stiemerling@nw.neclab.eu <== NEW ADDRESS > > NEC Laboratories Europe - Network Research Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 10:23:55 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ABCA28C1D4; Tue, 26 Feb 2008 10:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvB-CzH249RQ; Tue, 26 Feb 2008 10:23:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798C23A6C19; Tue, 26 Feb 2008 10:23:54 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2055F3A6CCB for ; Tue, 26 Feb 2008 10:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35WXHAq4CcAi for ; Tue, 26 Feb 2008 10:23:53 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D42093A680E for ; Tue, 26 Feb 2008 10:23:52 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2008 18:23:46 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.5]) [91.154.103.163] by mail.gmx.net (mp018) with SMTP; 26 Feb 2008 19:23:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/BwzoHOfDBIzVZrRyM4+JfEMVd2Rsznq0uNM1xUO mF71rzwe+oaOj/ Message-ID: <47C45927.3060102@gmx.net> Date: Tue, 26 Feb 2008 20:23:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: rucus BoF X-Y-GMX-Trusted: 0 Subject: [Rucus] Proposed Charter Text X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Here is the current proposal for the charter that includes some of suggestions I received. -------------- The Session Initiation Protocol (SIP) defines a system for user-to-user multimedia communications. Therefore, it is susceptible to unwanted communication attempts. RFC 5039 analyzes the problem of spam in SIP and examines various possible solutions that have been discussed for email and considers their applicability to SIP. RFC 5039 gives good, high-level recommendations regarding future work, namely * Strong Identity * White Lists * Solve the Introduction Problem * Don't Wait Until It's Too Late Strong identities and white lists will be essential but do do not address all problems. Among the challenges are compromised hosts controlled by a botnet, even with access to credentials, are the major source of email spam today and expected to remain the main source of SIP spam in the future. Among the many individual solution building blocks that are discussed in RFC 5039 (including content filtering, black lists, white lists, consent-based communication, reputation systems, address obfuscation, limited use addresses, turing tests, computational puzzles, payments at risk, circles of trust, and many others) there is no framework outlined how various mechanisms work together to produce a complete solution nor does the document attempt to offer a ranking to determine which solutions could form an initial set of candidate for subsequent standardization. This exploratory group chartered for one year aims to create a venue where discussions on unwanted communication in SIP can take place. The main goal of the group is to produce an architecture document that sheds light on the interworking between a minimal set of building blocks. The architectural investigations should cover different threat models, including those of compromised end hosts. The group will consider prior work on SIP identity and related techniques and will consult with privacy experts to deal with the regulatory aspects of blocking communication attempts. Outside the scope of the group are investigations in the area of voice analysis and algorithms for statistical analysis. Milestones Mar 08.....BoF @ IETF#71 Jul 08........Formation of an exploratory working group Jan 09.......First WG draft on the architecture document Jun 09.......Submit architecture document to the IESG for consideration as informational RFC Jul 09........Close group and decide on future work _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Feb 26 11:38:33 2008 Return-Path: X-Original-To: ietfarch-rucus-archive@core3.amsl.com Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8599F28C372; Tue, 26 Feb 2008 11:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, HTML_OBFUSCATE_05_10=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMA92W8rGXs6; Tue, 26 Feb 2008 11:38:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F0828C2E1; Tue, 26 Feb 2008 11:38:32 -0800 (PST) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE56A28C1FC for ; Tue, 26 Feb 2008 11:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkfW9qZ+yJXv for ; Tue, 26 Feb 2008 11:38:26 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id EEA8028C3B0 for ; Tue, 26 Feb 2008 11:37:43 -0800 (PST) Received: from [172.16.99.62] (account dyork [172.16.99.62] verified) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28226511; Tue, 26 Feb 2008 19:37:36 +0000 In-Reply-To: <47C38140.7000604@cisco.com> References: <47C38140.7000604@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <543FA876-3EB9-473B-8FE9-A23CA6791FBF@voxeo.com> From: Dan York Date: Tue, 26 Feb 2008 14:37:24 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.753) Cc: rucus@ietf.org Subject: Re: [Rucus] comments on draft-york-sipping-spit-similarity-scenarios-00 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1126321615==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1126321615== Content-Type: multipart/alternative; boundary=Apple-Mail-296-261661106 --Apple-Mail-296-261661106 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Jonathan, Thanks for the comments. Yes, notification systems have some characteristics that *should* enable downstream providers to be able to differentiate the traffic to a certain degree. However, as you note it *does* involve coordination with the downstream service provider. In many scenarios this may be possible. In others it may not. If you had a university of, say, 10,000 students and there was some notification, the outbound SIP messages might go to such places as: 1. SIP proxies and endpoints on campus under the control of university IT/telcom; 2. SIP proxies and endpoints on campus under the control of individual labs and departments; 3. SIP trunks to service providers providing connections to other SIP systems; 4. SIP trunks to service providers providing PSTN connectivity; 5. SIP -> PSTN gateways; 6. SIP gateways into mobile provider networks. And the list could go on in other environments, especially if the notification system uses SIP for not just phone notifications but also SMS or IM. In some of those cases you could have arrangements with the service providers so that they would know what to do if they received traffic from a particular server. In some of the other cases, it might be difficult. For instance, #2. My own experience with universities is that many times the labs and departments are all little fiefdoms that do things "their own way" and may not at all follow the lead of university IT. I agree with you that SIP identity (RFC 4474 and proposed extensions) would go far to assist in this differentiation. Regards, Dan On Feb 25, 2008, at 10:02 PM, Jonathan Rosenberg wrote: > Thanks for writing this up, Dan. > > Couple of comments. In many of the use cases you describe there is > probably some aspect of the system that allows these cases to be > differentiated from SPIT. For example, for emergency traffic, the fact > that the requests originated from the emergency notification server > tells its downstream proxy that this is not an attack. Similarly, the > domain that runs the emergency notification service would probably > tell > its downstream service provider that this can happen, and they can > agree > upon ways to separate this traffic out. This doesn't work in all cases > but in some. > > Also, using rfc4474 for these kinds of sources can help; since the set > of such sources is small you can use whitelisting in downstream > proxies > to deal with it. > > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > http://www.ietf.org/mailman/listinfo/rucus -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-296-261661106 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Jonathan,

Thanks = for the comments. =A0Yes, notification systems have some characteristics = that *should* enable downstream providers to be able to differentiate = the traffic to a certain degree. =A0However, as you note it *does* = involve coordination with the downstream service provider. =A0In many = scenarios this may be possible. =A0 In others it may not. =A0If you had = a university of, say, 10,000 students and there was some notification, = the outbound SIP messages might go to such places as:
=A0=A0 = 1. SIP proxies and endpoints on campus under the control of university = IT/telcom;
=A0=A0 2. SIP proxies and endpoints on campus under = the control of individual labs and departments;
=A0=A0 3. SIP = trunks to service providers providing connections to other SIP = systems;
=A0=A0 4. SIP trunks to service providers providing = PSTN connectivity;
=A0=A0 5. SIP -> PSTN = gateways;
=A0=A0 6. SIP gateways into mobile provider = networks.
And the list could go on in other environments, = especially if the notification system uses SIP for not just phone = notifications but also SMS or IM.

In some of those cases you = could have arrangements with the service providers so that they would = know what to do if they received traffic from a particular server. =A0In = some of the other cases, it might be difficult. =A0For instance, #2. =A0My= own experience with universities is that many times the labs and = departments are all little fiefdoms that do things "their own way" and = may not at all follow the lead of university IT.

I agree with you that SIP = identity (RFC 4474 and proposed extensions) would go far to assist in = this differentiation.=A0

Regards,
Dan
=



On Feb 25, 2008, = at 10:02 PM, Jonathan Rosenberg wrote:

Thanks for writing this up, Dan.

Couple = of comments. In many of the use cases you describe there is=A0
probably = some aspect of the system that allows these cases to be=A0
=A0
that the requests originated from the emergency = notification server=A0
tells = its downstream proxy that this is not an attack. Similarly, the=A0
domain = that runs the emergency notification service would probably tell=A0
its = downstream service provider that this can happen, and they can = agree=A0
upon ways to separate this traffic out. This doesn't = work in all cases=A0
but in some.

Also, using rfc4474 for these = kinds of sources can help; since the set=A0
of such = sources is small you can use whitelisting in downstream proxies=A0
to deal = with it.

Thanks,
Jonathan = R.

--=A0
Jonathan = D. Rosenberg, Ph.D. =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 499 Thornall St.
Cisco = Fellow =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Edison, NJ = 08837
Cisco, Voice Technology = Group
http://www.jdrosen.net =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 PHONE: (408) 902-3084
Rucus mailing list

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=
= --Apple-Mail-296-261661106-- --===============1126321615== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org http://www.ietf.org/mailman/listinfo/rucus --===============1126321615==--