From Hannes.Tschofenig@gmx.net Mon Mar 2 07:35:05 2009 Return-Path: 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 658603A6AE7 for ; Mon, 2 Mar 2009 07:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoKES8udsqdl for ; Mon, 2 Mar 2009 07:35:01 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0A9B13A69AC for ; Mon, 2 Mar 2009 07:35:00 -0800 (PST) Received: (qmail invoked by alias); 02 Mar 2009 15:35:25 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 02 Mar 2009 16:35:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+BK6xGgKWB83aaC6CXNsrktq5fIX6hl892zlZJza ctIim90WMXCgPt From: "Hannes Tschofenig" To: "'Hadriel Kaplan'" , "'Avasarala Ranjit-A20990'" , , References: <750BBC72E178114F9DC4872EBFF29A5B05F6EC3F@ZMY16EXM66.ds.mot.com> Date: Mon, 2 Mar 2009 17:36:26 +0200 Message-ID: <024b01c99b4c$a70c9810$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcmbExpd18YeURo2QKG8Gi9nzIAIBAALuTWQAAKgy7A= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Subject: Re: [Rucus] [Sipping] New Internet Draft for Caller Identity Blocking X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 15:35:05 -0000 How is this draft different from previously investigated approaches? http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 Ciao Hannes >-----Original Message----- >From: sipping-bounces@ietf.org >[mailto:sipping-bounces@ietf.org] On Behalf Of Hadriel Kaplan >Sent: 02 March, 2009 17:12 >To: Avasarala Ranjit-A20990; sipping@ietf.org >Subject: Re: [Sipping] New Internet Draft for Caller Identity Blocking > > >Hi Ranjit, >I like the purpose of your draft a lot, to let receiving users >block future calls from the same source. But I'm not sure the >implementation of it is quite right. It seems to me that if I >want to block a user from calling me indefinitely, I'd want it >to be known by more than the proxy chain sending it to me. In >particular, I'd probably want it to be known to the Registrar >or at least some database multiple proxies of my provider can >query. That way if there are multiple proxies which can reach >me, or the proxy is rebooted/replaced/whatever, or I move/roam >and end up using another proxy, the block-list is not lost. > >Obviously in a 3GPP-specific model you could have the S-CSCF >or some other node perform such an update to the HSS or >whatever, but then how would I unblock the user at some later >time, if I changed my mind? And how do I detect if my >operation succeeded, in case the proxy couldn't process my >block/unblock request? > >This seems more like a use-case for an event-package, where >one can send a PUBLISH to block/unblock users, or even a >Subscribe to view the current list. The tricky part with that >is that for some incoming calls there is no >caller-id/source-AoR for me to ask to be blocked or unblocked. > But since for that to be the case requires the proxy to >essentially be a B2BUA (to provide privacy anonymization, or >in 3GPP's case to remove and store the PAI), then one could >argue the PUBLISH can be sent to that same upstream B2BUA >which can insert that info if it still has it. (ugly, but >possible) Hmmm... I'll have to think about that issue more. > >Some other comments on your draft: >1) You show the Reason header being removed by the Proxy. >While that may make sense for some cases, for being out on >vacation it does not - I *want* the UAC to see it. >2) You describe the Reason header being inserted in >BYE/CANCEL, but in the example it's in a 4xx. Sending it in a >4xx failure response should be explicitly included, imho, even >though I think the Reason-header RFC didn't allow it (for some >whacky reason). >3) You add an Expires parameter (which should be lower-case, >by the way), and say if it's value is "99999" then it's >permanent, but meanwhile in one example a value of "604800" is >used for being on vacation. So clearly 99999 is not max. >Seems to me "99999" is a very small number, just slightly >longer than a day. :) Maybe just make it 4294967295 (an >unsigned long, 2^32-1, 136 years). >4) In the security section, it mentions integrity protection >to prevent snooping of messages when using this header. >AFAIK, integrity protection provides no eavesdropping >protection (that would be encryption); not that I can see why >it matters if someone snoops on this header anyway. You also >later cite TLS and S/MIME - I think you might as well remove >S/MIME since it's a waste of 6 characters in toner/ink if >anyone prints this draft out. ;) > >-hadriel > >________________________________________ >From: sipping-bounces@ietf.org >[mailto:sipping-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990 >Sent: Monday, March 02, 2009 3:45 AM >To: sipping@ietf.org >Subject: [Sipping] New Internet Draft for Caller Identity Blocking > >Hi All >I have just submitted an I-D on blocking caller identities >during ringing and call termination phases by extending SIP >Reason header to be included in SIP BYE and CANCEL methods. >Please review and comment >The URL of the draft is: >http://www.ietf.org/internet-drafts/draft-avasarala-sipping-rea >son-header-dynamic-icb-00.txt >Thanks >Regards >Ranjit >_______________________________________________ >Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP Use >sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP > From HKaplan@acmepacket.com Mon Mar 2 09:12:02 2009 Return-Path: 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 B1ED93A6AE7; Mon, 2 Mar 2009 09:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZ02L4ae55Kg; Mon, 2 Mar 2009 09:12:02 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D1D6E3A69D5; Mon, 2 Mar 2009 09:12:01 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 2 Mar 2009 12:12:27 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 2 Mar 2009 12:12:26 -0500 From: Hadriel Kaplan To: Hannes Tschofenig , 'Avasarala Ranjit-A20990' , "sipping@ietf.org" , "rucus@ietf.org" Date: Mon, 2 Mar 2009 12:12:25 -0500 Thread-Topic: [Sipping] New Internet Draft for Caller Identity Blocking Thread-Index: AcmbExpd18YeURo2QKG8Gi9nzIAIBAALuTWQAAKgy7AAAyStAA== Message-ID: References: <750BBC72E178114F9DC4872EBFF29A5B05F6EC3F@ZMY16EXM66.ds.mot.com> <024b01c99b4c$a70c9810$0201a8c0@nsnintra.net> In-Reply-To: <024b01c99b4c$a70c9810$0201a8c0@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Rucus] [Sipping] New Internet Draft for Caller Identity Blocking X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:12:02 -0000 Ignoring the syntax differences, even semantically they're different. One = is about indicating spam, the other is about asking for call blocking. Ind= icating spam might lead to call blocking, but not the other way around. Fo= r example just because I'm on vacation or don't want to get calls from you = in particular, does not mean your call is spam. It should not affect your = reputation, for example. And semantically the spam one is an indication, w= hereas the blocking one is a command, fwiw. Obviously the solution mechanism could be the same for both uses, I suppose= . (which is probably more to your point :) -hadriel > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, March 02, 2009 10:36 AM > To: Hadriel Kaplan; 'Avasarala Ranjit-A20990'; sipping@ietf.org; > rucus@ietf.org > Subject: RE: [Sipping] New Internet Draft for Caller Identity Blocking > > How is this draft different from previously investigated approaches? > http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 > > Ciao > Hannes > From Hannes.Tschofenig@gmx.net Mon Mar 2 09:40:25 2009 Return-Path: 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 C6AC128C16D for ; Mon, 2 Mar 2009 09:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJ7Rm0jPmPhu for ; Mon, 2 Mar 2009 09:40:25 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 858943A6AFA for ; Mon, 2 Mar 2009 09:40:21 -0800 (PST) Received: (qmail invoked by alias); 02 Mar 2009 17:40:45 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp055) with SMTP; 02 Mar 2009 18:40:45 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ICa5aYOoIYbWAgA/mQMkff7ZdfHe9C1n1FGkFlM PJUMYL1kgdNURW From: "Hannes Tschofenig" To: "'Hadriel Kaplan'" , "'Avasarala Ranjit-A20990'" , References: <750BBC72E178114F9DC4872EBFF29A5B05F6EC3F@ZMY16EXM66.ds.mot.com> <024b01c99b4c$a70c9810$0201a8c0@nsnintra.net> Date: Mon, 2 Mar 2009 19:41:44 +0200 Message-ID: <027101c99b5e$28c9ba70$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcmbExpd18YeURo2QKG8Gi9nzIAIBAALuTWQAAKgy7AAAyStAAAA5tdA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [Rucus] [Sipping] New Internet Draft for Caller Identity Blocking X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:40:25 -0000 -- dropping sipping >Ignoring the syntax differences, even semantically they're >different. One is about indicating spam, the other is about >asking for call blocking. The reason for asking calls to be blocked is important here. > Indicating spam might lead to call >blocking, but not the other way around. Yes, it would be good if something happens when you receive unwanted communication attempts. > For example just >because I'm on vacation or don't want to get calls from you in >particular, does not mean your call is spam. It should not >affect your reputation, for example. And semantically the >spam one is an indication, whereas the blocking one is a command, fwiw. When it is purely about configuring authorization policies then the following mechanism might be more appropriate: http://tools.ietf.org/html/draft-tschofenig-sipping-spit-policy-01 It re-uses mechanisms we have specified already elsewhere and can be outside a specific call establishment procedure (which is reasonable also in the on-vaction example you mentioned). A more sensible approach of handling my calls to you when you are on vaction is to forward my calls to your mailbox rather than blocking them and dropping them on the floor. Sure, it is your policy what todo with my calls but ... One of the mentioned examples, namely telemarketing, lead me to believe that this is not about configuring my buddy lists. >Obviously the solution mechanism could be the same for both >uses, I suppose. (which is probably more to your point :) > >-hadriel > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, March 02, 2009 10:36 AM >> To: Hadriel Kaplan; 'Avasarala Ranjit-A20990'; sipping@ietf.org; >> rucus@ietf.org >> Subject: RE: [Sipping] New Internet Draft for Caller >Identity Blocking >> >> How is this draft different from previously investigated approaches? >> http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 >> >> Ciao >> Hannes >> > From Hannes.Tschofenig@gmx.net Mon Mar 2 09:49:48 2009 Return-Path: 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 0ECB23A6C05 for ; Mon, 2 Mar 2009 09:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv+E1jdBY7rm for ; Mon, 2 Mar 2009 09:49:47 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4EE173A6BFF for ; Mon, 2 Mar 2009 09:49:45 -0800 (PST) Received: (qmail invoked by alias); 02 Mar 2009 17:50:11 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp067) with SMTP; 02 Mar 2009 18:50:11 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ID7whjiIIdxI+eDtwaKYUfK/txMxcrWAwypRwNm ucAwsWv4ZkDr82 From: "Hannes Tschofenig" To: "'Nils Ohlmeier'" , "'Avasarala Ranjit-A20990'" References: <750BBC72E178114F9DC4872EBFF29A5B05F6EC3F@ZMY16EXM66.ds.mot.com> Date: Mon, 2 Mar 2009 19:51:11 +0200 Message-ID: <030501c99b5f$7a1366a0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcmbWQZ8mdXNqAYVQzuLKNXCBfOz+wABV3HQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 Cc: rucus@ietf.org Subject: Re: [Rucus] [Sipping] New Internet Draft for Caller Identity Blocking X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:49:48 -0000 >And one more general comment very similar to Hadriels: >while I think the general idea of managing my >white-/grey-/black-lists instantenously is nice. But you are >basically only proposing a way to add something to a list and >push the responsibility for removal to a timer. I believe that >managing such an important list needs a lot more complex >management capabilities (querying, removal, modification,...). >If we have a solution for that, we could look for an easy way >how to combine that technique with direct feedback on an >incoming or terminated call. Nils, you are certainly right and these mechanisms have been developed already. See, for example, http://www.ietf.org/rfc/rfc5025.txt which builds on http://tools.ietf.org/html/rfc4745. Many of the clients have some form of buddy list management (+some possibility to block users). A protocol that allows these XML documents to be managed is available as well, namely XCAP. Similar mechanisms are available (and implemented) in XMPP. Ciao Hannes From victor.pascual.avila@gmail.com Wed Mar 4 10:05:30 2009 Return-Path: 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 56A0A3A698D for ; Wed, 4 Mar 2009 10:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjulvHdiDwEQ for ; Wed, 4 Mar 2009 10:05:29 -0800 (PST) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 837683A6B9C for ; Wed, 4 Mar 2009 10:05:27 -0800 (PST) Received: by ewy25 with SMTP id 25so2779023ewy.37 for ; Wed, 04 Mar 2009 10:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=n56U42Bqgt16kFeEWRlVFxxvCrI7068joW+gddOu37I=; b=XWQsbXezYvrnfvMZyntJzXO72LyS9dqTk79kq2KF+YUqQ2dnXD/VbUm3VqRDz/YrSg iBV5i3HAmwjQ2yf/pKyoHU/84SPfOLYkT7Lq1/MyFynaX23vvH5FnZxCWlLPY+JcB96c E06OIQ/QMVb7Vk3gAvsVm4dI4cQi3ydOP3B7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=v/R4x5PZM7o82GS1yYyFnqqnuYpDn2camqrwRvW7aLjytWIQaLsYaTMqrePhbBABUU HxLTpAmC2FEtGoeaUB3llchgl6j2kaLrUSwSL1CWvnibJVwjNrkVTtshDf6kxx0avuPX n4yHc1iyzOzgtjvZ8lPxk+u56NY47dwlU4eKU= MIME-Version: 1.0 Received: by 10.210.92.11 with SMTP id p11mr108865ebb.24.1236189955415; Wed, 04 Mar 2009 10:05:55 -0800 (PST) In-Reply-To: <323263D6-B104-4C13-8EC5-1FC4CFC3112C@voxeo.com> References: <323263D6-B104-4C13-8EC5-1FC4CFC3112C@voxeo.com> Date: Wed, 4 Mar 2009 19:05:55 +0100 Message-ID: <618e24240903041005y4b3400b1id4b3243e7ab1ffa7@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Dan York Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rucus@ietf.org BoF" Subject: Re: [Rucus] Actions coming out of informal RUCUS meeting at IETF 73 X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:05:30 -0000 Hi Folks, On Mon, Dec 1, 2008 at 6:07 PM, Dan York wrote: > Folks, > > At the informal RUCUS meeting at IETF 73 (see minutes here: > http://www.ietf.org/mail-archive/web/rucus/current/msg00347.html=C2=A0), = part of > the discussion was that while the charter for the RUCUS EG pointed at RFC > 5039, that RFC alone does not provide the whole picture of the issues aro= und > SPIT/spam. =C2=A0It was also pointed out that while many of us may be awa= re of > various different situations related to SPIT, much of that information ha= s > not been captured in any formal written documents but exists more in emai= l > threads or informal conversations. > > To that end, it was agreed that several people would write Internet-Draft= s > that document what is in fact going on out in actual deployments with reg= ard > to voice spam/SPIT and also spam in other areas. > > The list I have of who said they would submit a document is the following= : > > - David Schwartz about email spam and lessons from there. > - David Schwartz about the XConnect / Kayote experience thus far with SPI= T. > - Hannes Tschofenig about XMPP spam (and Hannes indicated he would contac= t > Peter St. Andre) > - Hendrik Scholz about the recent German SPIT attack (Jan Seedorf offered= to > help) > - Juergen Quitteck/Jan Seedorf about some of the cases they have seen in > their NEC incident database > - Jan Seedorf about the differences between DKIM and SIP Identity (Jan > agreed but indicated he would need the assistance of others in the room) > > It was agreed that these documents do NOT have to be long. They could be > just a page or two if that is all it takes to summarize the > incident/event/situation. =C2=A0The main point is to provide some written > background information for our continued discussions about SPIT and what = the > IETF can or cannot do (which would then lead to the brief mechanism-focus= ed > Internet-Drafts that are discussed in the RUCUS charter). > > We also agreed that these documents would be submitted as Internet-Drafts > because they then fit within the IETF workflow and are a standard format > that others involved with the IETF (but not necessarily RUCUS) can find a= nd > understand. > > We did not set a deadline at the meeting, but I would suggest that if we > could perhaps aim to have these brief documents put together by the end o= f > this month (Dec 2008) or by, say, January 15th, that would help. =C2=A0I = realize > with holidays that may be tough, but as soon as possible would be great. > =C2=A0I'd like to make the case to the ADs that RUCUS should have a forma= l time > slot at IETF 74, but for that to occur we need to have some forward > momentum. =C2=A0If we could have these summary documents in by mid-Januar= y, that > gives us some time to pull together some mechanism-related drafts before = the > March meeting in SF that could then warrant some real face-to-face > discussion. Is any of these documents ready for discussion? Cheers, --=20 Victor Pascual =C3=81vila From dschwartz@xconnect.net Mon Mar 9 03:36:02 2009 Return-Path: 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 854DB3A69A6 for ; Mon, 9 Mar 2009 03:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.485 X-Spam-Level: X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 E1K+BqOGc30B for ; Mon, 9 Mar 2009 03:36:01 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by core3.amsl.com (Postfix) with ESMTP id A109F3A693E for ; Mon, 9 Mar 2009 03:36:00 -0700 (PDT) Received: from [10.0.1.198] (bzq-219-150-62.static.bezeqint.net [62.219.150.62]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1LgcqS3oQD-0007fH; Mon, 09 Mar 2009 11:36:31 +0100 Message-Id: <2185BC71-EFC0-4E5C-84DD-D22DB0D459D5@xconnect.net> From: David Schwartz To: "Saverio Niccolini" In-Reply-To: <547F018265F92642B577B986577D671C70099F@VENUS.office> Content-Type: multipart/alternative; boundary=Apple-Mail-24-589749995 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 12:36:27 +0200 References: <004601c99dbd$644f2ce0$0201a8c0@nsnintra.net> <49B4E26B.5070808@alcatel-lucent.fr> <5E6680AC-3A45-46AC-933D-033CFAA0FBE2@xconnect.net> <547F018265F92642B577B986577D671C70099F@VENUS.office> X-Mailer: Apple Mail (2.930.3) X-Provags-ID: V01U2FsdGVkX1/AbJBdquja8PEzhtL2o/ipWuDp/PYsueEzQJF 7JbLpF4VvIP6dgqGL6u6qTJFh9TnI6MlpUQYWOTYiARhlZLOWr /dkol217l+rABDidAYRRQ== Cc: rucus BoF Subject: Re: [Rucus] SPIT Documents: Resubmission Useful? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 10:36:02 -0000 --Apple-Mail-24-589749995 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Saverio I wasn't referring to getting the EG approved (not sure that is =20 possible :)) just stating that I liked Hannes's doc. If I have to seriously think about how to get the EG (or better yet =20 WG) off the ground - Perhaps if we focus on where there is pain TODAY =20= (vishing?) This is a link to a whitepaper written for the National Consumer =20 League on phishing. Now while this is completely email oriented their =20= conclusions (no real news - actually) can guide us as well. http://www.nclnet.org/news/2006/Final%20NCL%20Phishing%20Report.pdf pp 49. "In the case of Phishing, lack of strong mutual authentication and the =20= use of shared secrets may be the primary reasons Bad Guys continue to utilize the =20 technique. They can pretend to be your bank or a trusted entity you do business with and unless you=92re an =20 expert, it=92s very hard for you to tell the site isn=92t real. You type in your secrets (your credentials) and the Bad =20= Guys later play them back to the entity and pretend to be you. Adding a =93second factor=94 like a one time password = =20 will not help you recognize the site is spoofed and it can still be replayed by the Bad Guy via a classic man-=20= in-the-middle attack. These issues call for a strategy which makes it easier for users to =20 assess whether they are on the correct site (i.e., stronger mutual authentication) and moves away from using =20 shared secrets to authenticate (e.g., username and password). Using Public Key Cryptography, where the =93private key=94 = =20 stays private and only the =93public key=94 is exchanged over the Internet, is one way to take away the prize = =20 sought by the Phisher. " Note that the attached appendix is quite illuminating as well. D. On Mar 9, 2009, at 11:55 AM, Saverio Niccolini wrote: > I like Hannes document as well and we took as a reference for > several improvements here from an implementation perspective > anyway: > I still do not see how such a document would help us in getting > the EG approved... which is what we were aiming at... > > Do you have thoughts on this? > 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 > Manager, Real-Time Communications Group > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: David Schwartz [mailto:dschwartz@xconnect.net] >> Sent: 09 March 2009 10:42 >> To: Thomas Froment >> Cc: Hannes Tschofenig; Dan Wing; Martin Stiemerling; Henning >> Schulzrinne; Saverio Niccolini; Jonathan Rosenberg; = gdawirs@gdawirs.be=20 >> ; >> mayutan.arumaithurai@gmail.com; eva.leppanen@hukassa.com >> Subject: Re: SPIT Documents: Resubmission Useful? >> >> Hi Hannes and sorry for taking so long to get back to you on this. >> >> While I agree in principle with Dans assessment that most of these >> ideas should just be allowed to perish (for now) I would contend that >> the one exception is the framework document that you had set out to >> write. >> >> Regardless of the eventual solution it is clear that many players or >> entities will have to work in concert and your framework doc began to >> address just that. >> >> Just my 2 cents, >> >> D. >> >> >> >> On Mar 9, 2009, at 11:33 AM, Thomas Froment wrote: >> >>> Hannes Tschofenig wrote: >>>> Hi all, >>>> We have worked on a couple of documents related to tackle spam and >>>> unwanted >>>> communication. The topic stalled a bit after the RUCUS BOF. >>>> I am not sure whether there isn't really a problem with SIP spam at >>>> the >>>> moment or whether the interest in this topic has completely >>>> vanished in the >>>> IETF. >>>> Does it makes any sense to resubmit our documents or todo anything >>>> else? >>>> Your feedback is appreciated. >>> Hi Hannes, >>> >>> I would be in favor of resubmitting the documents on SPIT policies >>> because I personnally think this is one >>> the important piece to fight SPIT without having to address the >>> endless question of SPIT *detection* (which is probably >>> out of IETF scope by the way). >>> >>> That being said, I don't plan to work on it, and I won't attend >>> IETF meetings anymore in a near future, so, not sure >>> this will help the topic moving forward at IETF... >>> >>> Thomas >>> >>> >>> >>> >> = ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security =20 >>> System. >>> For more information please visit http://www.messagelabs.com/email >>> >> = ______________________________________________________________________ > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ --Apple-Mail-24-589749995 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Saverio

I = wasn't referring to getting the EG approved (not sure that is possible = :)) just stating that I liked Hannes's doc.

If = I have to seriously think about how to get the EG (or better yet WG) off = the ground - Perhaps if we focus on where there is pain TODAY = (vishing?)

This is a link to a whitepaper = written for the National Consumer League on phishing. Now while this is = completely email oriented their conclusions (no real news - actually) = can guide us as well.


pp 49. 

"In = the case of Phishing, lack of strong mutual authentication and the use = of shared 
 
bank or a trusted entity you do = business with and unless you=92re an expert, it=92s very hard for you to = tell the site 
isn=92t real. You type in your = secrets (your credentials) and the Bad Guys later play them back to the = entity and 
 
spoofed and it can still be replayed = by the Bad Guy via a classic man-in-the-middle attack. 
These issues call for a strategy = which makes it easier for users to assess whether they are on the = correct site 
(i.e., stronger mutual = authentication) and moves away from using shared secrets to authenticate = (e.g., username 
and password). Using Public Key = Cryptography, where the =93private key=94 stays private and only the = =93public 
key=94 = is exchanged over the Internet, is one way to take away the prize sought = by the Phisher. "

Note that the attached appendix is quite illuminating = as well.

D.
I = like Hannes document as well and we took as a reference for
several = improvements here from an implementation perspective
anyway:
I = still do not see how such a document would help us in getting
the EG = approved... which is what we were aiming at...

Do you have = thoughts on = this?
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
Manager, Real-Time Communications Group
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: David Schwartz [mailto:dschwartz@xconnect.net]<= br>
Sent: 09 March 2009 = 10:42
To: Thomas = Froment
Cc: Hannes Tschofenig; = Dan Wing; Martin Stiemerling; Henning
Schulzrinne; Saverio Niccolini; Jonathan Rosenberg; gdawirs@gdawirs.be;
mayutan.arumaithurai@gmail.= com; eva.leppanen@hukassa.com
<= /blockquote>
Subject: Re: SPIT Documents: = Resubmission Useful?

Hi Hannes and = sorry for taking so long to get back to you on = this.

While I agree = in principle with Dans assessment that most of = these
ideas should just be = allowed to perish (for now) I would contend = that
the one exception is the = framework document that you had set out to
write.

Regardless of = the eventual solution it is clear that many players = or
entities will have to work = in concert and your framework doc began to
address just that.

Just my 2 = cents,

D.



On Mar 9, 2009, = at 11:33 AM, Thomas Froment wrote:

Hannes Tschofenig = wrote:
Hi = all,
We = have worked on a couple of documents related to tackle spam = and
unwanted
communication. The topic stalled a bit after the RUCUS = BOF.
I am = not sure whether there isn't really a problem with SIP spam = at
the
moment = or whether the interest in this topic has = completely
vanished= in the
IETF.
Does = it makes any sense to resubmit our documents or todo = anything
else?
Your = feedback is = appreciated.
Hi = Hannes,

I would be in favor of = resubmitting the documents on SPIT = policies
because I personnally think this = is one
the important piece to fight SPIT without having to = address the
endless question of SPIT = *detection* (which is probably
out of IETF scope by the = way).

That being said, I don't plan to = work on it,  and I won't = attend
IETF meetings anymore in a near future, so, not = sure
this will help the topic moving forward at = IETF...

Thomas




____________________________________________________________= __________
This email has been scanned by the MessageLabs Email = Security System.
For more information please = visit http://www.messagelabs.com/email=

____________________________________________________________= __________


_______________________________________= _______________________________
This email has been scanned by the = MessageLabs Email Security System.
For more information please visit = http://www.messagelabs.com/email= =
______________________________________________________________________=

= --Apple-Mail-24-589749995--