From root@core3.amsl.com Wed Apr 1 00:00:02 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 095B73A6BD6; Wed, 1 Apr 2009 00:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090401070002.095B73A6BD6@core3.amsl.com> Date: Wed, 1 Apr 2009 00:00:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-199-07.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 07:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sip-199-07.txt Pages : 14 Date : 2009-03-31 This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and a UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-199-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-31235733.I-D@ietf.org> --NextPart-- From christer.holmberg@ericsson.com Wed Apr 1 01:08:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A503A6A30 for ; Wed, 1 Apr 2009 01:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBfPEQRwIIM5 for ; Wed, 1 Apr 2009 01:08:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7F2AC3A680B for ; Wed, 1 Apr 2009 01:08:56 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 706382288E for ; Wed, 1 Apr 2009 09:31:00 +0200 (CEST) X-AuditID: c1b4fb3c-aef61bb000003f6e-91-49d3182f27c2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BB6E122881 for ; Wed, 1 Apr 2009 09:30:55 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 09:30:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B29B.C37B25D5" Date: Wed, 1 Apr 2009 09:30:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new version: draft-ietf-sip-199-07 Thread-Index: Acmym8OanYrcZUyMQeinTO+WHiaadQ== From: "Christer Holmberg" To: X-OriginalArrivalTime: 01 Apr 2009 07:30:42.0545 (UTC) FILETIME=[C371A610:01C9B29B] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:08:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B29B.C37B25D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have put together a new version (-07) of the 199 draft, based on the latest discussions. The changes are in chapters 5 (new note added) and 6 (text simplified). 100rel and SDP o/a impacts have also been added to chapters 5 and 6 (I have still kept chapters 9 and 10, though). http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt Regards, Christer ------_=_NextPart_001_01C9B29B.C37B25D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: draft-ietf-sip-199-07

Hi,

I have put together a new version (-07) = of the 199 draft, based on the latest discussions.

The changes are in chapters 5 (new note = added) and 6 (text simplified). 100rel and SDP o/a impacts have also = been added to chapters 5 and 6 (I have still kept chapters 9 and 10, = though).

http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt=

Regards,

Christer

------_=_NextPart_001_01C9B29B.C37B25D5-- From john.elwell@siemens-enterprise.com Wed Apr 1 03:32:50 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F553A67A7 for ; Wed, 1 Apr 2009 03:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.048, 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 7m1f9rgDf7YZ for ; Wed, 1 Apr 2009 03:32:50 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id C2E0A3A6B27 for ; Wed, 1 Apr 2009 03:32:49 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHF00K02408O9@siemenscomms.co.uk> for sip@ietf.org; Wed, 01 Apr 2009 11:33:44 +0100 (BST) Date: Wed, 01 Apr 2009 11:33:43 +0100 From: "Elwell, John" In-reply-to: <618e24240903310306k61cefe0cwb71848b3d78a7e50@mail.gmail.com> To: =?iso-8859-1?Q?Victor_Pascual_=C1vila?= , Jonathan Rosenberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001B51BFF@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Media vs Signaling identity (was Re: francois' comments andwhy RFC4474 not used in the field) Thread-Index: Acmx6H6yau7jf0o5ScWIm32Nejp1AwAwcoyQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <618e24240903310306k61cefe0cwb71848b3d78a7e50@mail.gmail.com> Cc: SIP List Subject: Re: [Sip] Media vs Signaling identity (was Re: francois' comments andwhy RFC4474 not used in the field) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 10:32:50 -0000 =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Victor Pascual =C1vila > Sent: 31 March 2009 11:07 > To: Jonathan Rosenberg > Cc: SIP List > Subject: [Sip] Media vs Signaling identity (was Re: francois'=20 > comments andwhy RFC4474 not used in the field) >=20 > On Tue, Mar 31, 2009 at 4:12 AM, Jonathan Rosenberg=20 > wrote: > > inline: > > > > Jiri Kuthan wrote: > > > > > >>> =A0From an end user perspective, I would assert that the=20 > most important > >>> thing is probably the media. If the callerID says, "this=20 > is bob", what is > >>> important to the user, is that when I pick up the phone=20 > and start talking, > >>> it will be Bob who hears me, and Bob that I hear. > >>> > >>> Consider this litmus test: > >>> > >>> If the signaling actually came from Mary (perhaps as a=20 > third party), but > >>> the media goes/comes to/from Bob, who should appear on=20 > the caller ID? I say > >>> - Bob. > >> > >> There is a timing aspect in favor of placing identity in=20 > signaling -- > >> I would like to know whose call is ringing before I answer=20 > (if I do). > > > > You can still have that. Just don't ring the phone until=20 > early media has > > been exchanged and verified. Indeed if you were doing an=20 > ICE-style thing per > > Dan's draft, you'd get that for free. >=20 > Are we restricting the identity assertion to telephony-like sessions? >=20 > IMHO, identity assertion should also work for the following scenarios > (among others): >=20 > -rfc3725, figure 1, message 1 (INVITE no SDP): Upon receipt of the > initial INVITE (note there's no session description at all), "A" > decides to authorize or reject the call based on the delivered > identifier. >=20 > -rfc3428, figure 1, message 2 (F2): "user2" decides to answer or > ignore the message based on the delivered identifier. >=20 > -rfc3515, example 4.1, message 1 (F1): "agent B" decides to accept or > reject the refer based on the delivered identifier >=20 > -Any other application based on white/black lists (where the identity > verification must happen before accepting a request). >=20 >=20 > While "signaling identity" seems to be a common denominator, I'm not > sure about the role of "media identity" in the above listed scenarios. > Any clarification will be appreciated. [JRE] These too are valid situations where the identity needs to be = authenticated. Where media is involved, however, there is an additional = problem of authenticating the media, and if the media is bound to the = signalling, a solution for authenticating the signalling would also = authenticate the media. So we either need a solution for authenticating = both signalling and media together (e.g., by authenticating the = signalling, the media too gets authenticated) or we need separate = mechanisms. Clearly the former would be preferable. John >=20 > Cheers, > --=20 > Victor Pascual =C1vila > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From john.elwell@siemens-enterprise.com Wed Apr 1 03:32:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 582E03A67A7 for ; Wed, 1 Apr 2009 03:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 GoKQbB4-DZlT for ; Wed, 1 Apr 2009 03:32:50 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 370F93A6C5B for ; Wed, 1 Apr 2009 03:32:50 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHF00K07409O9@siemenscomms.co.uk> for sip@ietf.org; Wed, 01 Apr 2009 11:33:45 +0100 (BST) Date: Wed, 01 Apr 2009 11:33:44 +0100 From: "Elwell, John" In-reply-to: <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> To: Cullen Jennings , "DRAGE, Keith (Keith)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmyaKIrc8L0E8LqT+OUkU6/Sj2JXAAROLSw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 10:32:51 -0000 I would like service providers to chip in here. Suppose I use service providers to establish a call between two enterprises. Enterprise A uses SP A for all external traffic, and enterprise B uses SP B for all external traffic. We then have a path: Enterprise A -> SP A -> SP B -> Enterprise B. What I would like to know is whether SP A and/or SP B would have reason to change the SDP (also other aspects of the SIP request, but just stick to SDP for now). If they need to change it, then what drives this need to change the SDP: NAT traversal, topology hiding, media steering, ....? If SPs think they have no reason to change SDP in such situations, then this part of the problem is solved. However, I very much doubt that is the case. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Cullen Jennings > Sent: 01 April 2009 02:24 > To: DRAGE, Keith (Keith) > Cc: sip@ietf.org; Francois Audet > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > In all of section 8, the only reason I find of why things are=20 > changed is >=20 > "For media steering purposes, B2BUAs in intermediate domains need to =20 > modify the IP address c-lines and the port in m-lines." > Even this one line leaves me confused about what intermediate=20 > domains =20 > are in the deployment cases where this happens and if we are talking =20 > about email style address or e.164 style addresses. What an=20 > example is =20 > of a deployment where things like this happen and why the=20 > middle (not =20 > the end domains) do the media steering. When I ask this of example =20 > people give me, if often turns out what is really wanted is=20 > not media =20 > steering but the middle to be able to hide the fact that they=20 > actually =20 > delivered the call to a third provider for PSTN termination. >=20 > Pretend 4474 does not even exist for a minute. I don't think it is =20 > unrealizable of me to ask what the problem is we are trying=20 > to solve. =20 > Saying 4474 is does not solve the problem may or may not be true but =20 > we are unlikely to have a good conversation about about what=20 > we should =20 > do until we understand what we are trying to accomplish. >=20 >=20 > On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote: >=20 > > Cullen wrote: > > > > > The thing I keep asking is can we make a list of reason why > > > SDP and headers get changes and in what scenarios they do > > > this. I think it will be hard to sort how to fix this without > > > being clear what needs to be fixed. > > > > > > > Isn't that the function of the text that was placed in section 8 of > > > >=20 > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 > > > > If it is not, then what do you think is missing. > > > > regards > > > > Keith > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of Cullen Jennings > > > Sent: Tuesday, March 31, 2009 11:32 PM > > > To: Jiri Kuthan > > > Cc: sip@ietf.org; Francois Audet > > > Subject: Re: [Sip] francois' comments and why RFC4474 not > > > used in the field > > > > > > > > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: > > > > > > > > > > > I'm worried this is only a wishful thinking. While > > > perfectly logical, > > > > still even in such constrained setups some bizzar ALGs do in my > > > > experience appear in the middle, change SDP and make thus > > > the identity > > > > worthless. > > > > > > The thing I keep asking is can we make a list of reason why > > > SDP and headers get changes and in what scenarios they do > > > this. I think it will be hard to sort how to fix this without > > > being clear what needs to be fixed. > > > > > > For example, one of the things we might want to say is > > > something like: > > > the Phone is behind a NAT and connects to it's proxy / > > > registrar for its' domain. That proxy/b2bua whatever mucks > > > with IP/ports in the SDP for NAT traversal. Then we could ask > > > if 4474 is broken in this case or not and what might be a > > > good way of solving the problem of having UAs behind NATs. > > > > > > Cullen > > > > > > _______________________________________________ > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the=20 > application of sip > > > >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From victor.pascual.avila@gmail.com Wed Apr 1 06:19:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A6D3A69B1 for ; Wed, 1 Apr 2009 06:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.037, 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 0MLWxk+HdQkW for ; Wed, 1 Apr 2009 06:19:47 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 734763A690F for ; Wed, 1 Apr 2009 06:19:47 -0700 (PDT) Received: by ewy9 with SMTP id 9so23990ewy.37 for ; Wed, 01 Apr 2009 06:20:46 -0700 (PDT) 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=onca91yZgMOi6De4AO8gUo+58yIJ4oepcrrJxczpy3I=; b=kY78eri/TiGmzJ8c/W3D3xhG7eOjs6rVx4yLXCN3VmcKLfVV9cYNEbYwt4PY/OqpG1 2R+Ppzfljfrvt/0dhdTmu1tVvWer/jz4EwKBRu3+d0U0yyFab9jqoIA8Uu3vcAEYo760 YwvZUF79tVlmqny9li2hSJG3mW4+Ax+90lbEo= 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=CuL1+xZ5XOMc6rCM3+QX95unBZGygZEZclGXZ7rgPTz2EE6jiOjvKHlTRPT1FJ+bfV Pwpx7HHcb0XSYU7WmFCun2osJxz0EJPbnhSbRX3FCo3fGrgwna9KPlv7qItEFDEcLi6/ fA7o0wR0aE+NJW+1lDFXsSEvQoeGD8aTwPlKo= MIME-Version: 1.0 Received: by 10.210.19.7 with SMTP id 7mr5995542ebs.15.1238592046723; Wed, 01 Apr 2009 06:20:46 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001B51BFF@GBNTHT12009MSX.gb002.siemens.net> References: <618e24240903310306k61cefe0cwb71848b3d78a7e50@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51BFF@GBNTHT12009MSX.gb002.siemens.net> Date: Wed, 1 Apr 2009 15:20:46 +0200 Message-ID: <618e24240904010620t743f612dtf207c4efcdade223@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: "Elwell, John" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: SIP List Subject: Re: [Sip] Media vs Signaling identity (was Re: francois' comments andwhy RFC4474 not used in the field) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 13:19:48 -0000 On Wed, Apr 1, 2009 at 12:33 PM, Elwell, John wrote: (snip) >> While "signaling identity" seems to be a common denominator, I'm not >> sure about the role of "media identity" in the above listed scenarios. >> Any clarification will be appreciated. > [JRE] These too are valid situations where the identity needs to be authe= nticated. Where media is involved, however, there is an additional problem = of authenticating the media, and if the media is bound to the signalling, a= solution for authenticating the signalling would also authenticate the med= ia. So we either need a solution for authenticating both signalling and med= ia together (e.g., by authenticating the signalling, the media too gets aut= henticated) or we need separate mechanisms. Clearly the former would be pre= ferable. I guess we all agree that the following scenarios are possible (please correct me if I'm wrong): + Only Signaling (e.g. sender-to-receiver MESSAGE ): we need to authenticate the signaling itself. Here we are including scenarios where user content is embedded into the signaling plane. + Signaling and media: we need to authenticate both signaling and media pla= nes -+ Media is bound to the signaling (e.g. caller-to-callee INVITE-transaction + caller-to-callee rtp stream(s)): we may need to authenticate both signaling and media together. (BTW, I fail to see the benefits of coupling media and control plane identities; specially when considering Lawful Interception) -+ Media is not bound to the signaling (e.g. 3PCC): we may need separate mechanisms Which scenarios are we trying to cover here? Is the receiver identity (media or signaling) as important as the sender identity? Just trying to find some rough consensus and narrow the "identity problem", --=20 Victor Pascual =C3=81vila From timothy.dwight@verizon.com Wed Apr 1 07:11:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63EE3A6BA4 for ; Wed, 1 Apr 2009 07:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 yMW1G-xtVqCk for ; Wed, 1 Apr 2009 07:11:02 -0700 (PDT) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id 867933A6888 for ; Wed, 1 Apr 2009 07:11:02 -0700 (PDT) Received: from pdcismtp02.vzbi.com ([166.40.77.70]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHF00JC8DZFS900@firewall.verizonbusiness.com> for sip@ietf.org; Wed, 01 Apr 2009 14:09:16 +0000 (GMT) Received: from pdcismtp02.vzbi.com ([127.0.0.1]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHF008G2DZFVV00@pdcismtp02.vzbi.com> for sip@ietf.org; Wed, 01 Apr 2009 14:09:15 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([153.39.68.168]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHF0085SDZEWV00@pdcismtp02.vzbi.com> for sip@ietf.org; Wed, 01 Apr 2009 14:09:15 +0000 (GMT) Received: from ASHEVS015.vzbi.com ([153.39.71.98]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 01 Apr 2009 14:09:15 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Date: Wed, 01 Apr 2009 14:09:11 +0000 Message-id: In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-index: AcmyaKIrc8L0E8LqT+OUkU6/Sj2JXAAROLSwAAgiMOA= References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> From: "Dwight, Timothy M (Tim)" To: "Elwell, John" , Cullen Jennings , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 01 Apr 2009 14:09:15.0302 (UTC) FILETIME=[708ECC60:01C9B2D3] X-Mailman-Approved-At: Wed, 01 Apr 2009 07:22:14 -0700 Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:11:03 -0000 John, In my experience, service providers (such as the one I work for) sometimes change the SDP in situations like this, and sometimes don't. It depends on whether the service providers' VoIP infrastructure is in the public Internet address space, or a private address space (e.g., MPLS/BGP -based VPN). Use of the latter configuration requires NAT and SIP ALG functionality "at the edge". In the diagram below there is an "edge" everywhere you draw an arrow. Typically the devices that implement the NAT and SIP ALG functions do other things, like topology hiding and steering the media to a device that will then monitor ("police") its arrival rate. Alternatively, if the SP's infrastructure is in the public address space, you typically don't see NAT / SIP ALG or topology hiding or media steering. You may (often do) still see "border devices" doing things like traffic aggregation and policy based routing. In either case, it's not uncommon that the border elements modify other aspects of the SIP signaling for reasons of interoperability. For example it's sometimes [believed to be] necessary to modify response codes due to differing implementations - e.g., to break an infinite-retry loop. tim =20 > I would like service providers to chip in here. Suppose I use service > providers to establish a call between two enterprises. Enterprise A uses > SP A for all external traffic, and enterprise B uses SP B for all > external traffic. We then have a path: >=20 > Enterprise A -> SP A -> SP B -> Enterprise B. >=20 > What I would like to know is whether SP A and/or SP B would have reason > to change the SDP (also other aspects of the SIP request, but just stick > to SDP for now). If they need to change it, then what drives this need > to change the SDP: NAT traversal, topology hiding, media steering, ....? >=20 > If SPs think they have no reason to change SDP in such situations, then > this part of the problem is solved. However, I very much doubt that is > the case. >=20 > John >=20 >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > > Behalf Of Cullen Jennings > > Sent: 01 April 2009 02:24 > > To: DRAGE, Keith (Keith) > > Cc: sip@ietf.org; Francois Audet > > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > > used in the field > >=20 > >=20 > > In all of section 8, the only reason I find of why things are=20 > > changed is > >=20 > > "For media steering purposes, B2BUAs in intermediate=20 > domains need to =20 > > modify the IP address c-lines and the port in m-lines." > > Even this one line leaves me confused about what intermediate=20 > > domains =20 > > are in the deployment cases where this happens and if we=20 > are talking =20 > > about email style address or e.164 style addresses. What an=20 > > example is =20 > > of a deployment where things like this happen and why the=20 > > middle (not =20 > > the end domains) do the media steering. When I ask this of example =20 > > people give me, if often turns out what is really wanted is=20 > > not media =20 > > steering but the middle to be able to hide the fact that they=20 > > actually =20 > > delivered the call to a third provider for PSTN termination. > >=20 > > Pretend 4474 does not even exist for a minute. I don't think it is =20 > > unrealizable of me to ask what the problem is we are trying=20 > > to solve. =20 > > Saying 4474 is does not solve the problem may or may not be=20 > true but =20 > > we are unlikely to have a good conversation about about what=20 > > we should =20 > > do until we understand what we are trying to accomplish. > >=20 > >=20 > > On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote: > >=20 > > > Cullen wrote: > > > > > > > The thing I keep asking is can we make a list of reason why > > > > SDP and headers get changes and in what scenarios they do > > > > this. I think it will be hard to sort how to fix this without > > > > being clear what needs to be fixed. > > > > > > > > > > Isn't that the function of the text that was placed in=20 > section 8 of > > > > > >=20 > >=20 > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 > > > > > > If it is not, then what do you think is missing. > > > > > > regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > > Behalf Of Cullen Jennings > > > > Sent: Tuesday, March 31, 2009 11:32 PM > > > > To: Jiri Kuthan > > > > Cc: sip@ietf.org; Francois Audet > > > > Subject: Re: [Sip] francois' comments and why RFC4474 not > > > > used in the field > > > > > > > > > > > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: > > > > > > > > > > > > > > I'm worried this is only a wishful thinking. While > > > > perfectly logical, > > > > > still even in such constrained setups some bizzar=20 > ALGs do in my > > > > > experience appear in the middle, change SDP and make thus > > > > the identity > > > > > worthless. > > > > > > > > The thing I keep asking is can we make a list of reason why > > > > SDP and headers get changes and in what scenarios they do > > > > this. I think it will be hard to sort how to fix this without > > > > being clear what needs to be fixed. > > > > > > > > For example, one of the things we might want to say is > > > > something like: > > > > the Phone is behind a NAT and connects to it's proxy / > > > > registrar for its' domain. That proxy/b2bua whatever mucks > > > > with IP/ports in the SDP for NAT traversal. Then we could ask > > > > if 4474 is broken in this case or not and what might be a > > > > good way of solving the problem of having UAs behind NATs. > > > > > > > > Cullen > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the=20 > > application of sip > > > > > >=20 > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From ietf.hanserik@gmail.com Wed Apr 1 07:22:33 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BA03A6B86 for ; Wed, 1 Apr 2009 07:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, HTML_MESSAGE=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 2un72WLM1yLZ for ; Wed, 1 Apr 2009 07:22:31 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id BA4EF3A6B60 for ; Wed, 1 Apr 2009 07:22:27 -0700 (PDT) Received: by ewy9 with SMTP id 9so52950ewy.37 for ; Wed, 01 Apr 2009 07:23:27 -0700 (PDT) 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; bh=GA+n4zmOVuniMiDvo7WSsJ6WspFWmb8c1yI7BOfcg9g=; b=gxps1QJ0O4CTEAhEUbqQNHttujkBLZp8vMZo/8JshYP225o7Qi2RMuRbrHi5fzPUwT Qyg5vTJANjso+ij6Fcgd42oDU3bpzRGF4grBhShsnpNvJCFKSxJKtM1Ctym8RR/rq2IB DqjAEqd7WJ/e+DY2uwzMY+nyc8HqvGNXVSW9o= 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; b=L4SJSrBESPBWOBbQuGROEOxMxVXojLCW/UfPsvY8oDvoqEQ2O0VkNDWJeQa3ABeTun vR28clXHA8qXYMOAE/UQfN9GpLN8Xl0VFR/YXUou4ZxgyOUW0i2mhRR6X/L3x+oDAtVl DRJ6dgmnfiVpeQJRmLx8d+Ko8nhGnYkKk2Z4A= MIME-Version: 1.0 Received: by 10.216.45.65 with SMTP id o43mr2311837web.4.1238595807390; Wed, 01 Apr 2009 07:23:27 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> Date: Wed, 1 Apr 2009 16:23:27 +0200 Message-ID: <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=0016367d6a3c1eaca404667f0ffa Cc: Cullen Jennings , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:22:33 -0000 --0016367d6a3c1eaca404667f0ffa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In that scenario you have probably passed 6 SBC's :-) Enterprise A (SBC1) -> (SBC2) SP A (SBC3)->(SBC4) SP B (SBC5)-> (SBC6) Enterprise B. /Hans Erik van Elburg On Wed, Apr 1, 2009 at 12:33 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > I would like service providers to chip in here. Suppose I use service > providers to establish a call between two enterprises. Enterprise A uses > SP A for all external traffic, and enterprise B uses SP B for all > external traffic. We then have a path: > > Enterprise A -> SP A -> SP B -> Enterprise B. > > What I would like to know is whether SP A and/or SP B would have reason > to change the SDP (also other aspects of the SIP request, but just stick > to SDP for now). If they need to change it, then what drives this need > to change the SDP: NAT traversal, topology hiding, media steering, ....? > > If SPs think they have no reason to change SDP in such situations, then > this part of the problem is solved. However, I very much doubt that is > the case. > > John > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Cullen Jennings > > Sent: 01 April 2009 02:24 > > To: DRAGE, Keith (Keith) > > Cc: sip@ietf.org; Francois Audet > > Subject: Re: [Sip] francois' comments and why RFC4474 not > > used in the field > > > > > > In all of section 8, the only reason I find of why things are > > changed is > > > > "For media steering purposes, B2BUAs in intermediate domains need to > > modify the IP address c-lines and the port in m-lines." > > Even this one line leaves me confused about what intermediate > > domains > > are in the deployment cases where this happens and if we are talking > > about email style address or e.164 style addresses. What an > > example is > > of a deployment where things like this happen and why the > > middle (not > > the end domains) do the media steering. When I ask this of example > > people give me, if often turns out what is really wanted is > > not media > > steering but the middle to be able to hide the fact that they > > actually > > delivered the call to a third provider for PSTN termination. > > > > Pretend 4474 does not even exist for a minute. I don't think it is > > unrealizable of me to ask what the problem is we are trying > > to solve. > > Saying 4474 is does not solve the problem may or may not be true but > > we are unlikely to have a good conversation about about what > > we should > > do until we understand what we are trying to accomplish. > > > > > > On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote: > > > > > Cullen wrote: > > > > > > > The thing I keep asking is can we make a list of reason why > > > > SDP and headers get changes and in what scenarios they do > > > > this. I think it will be hard to sort how to fix this without > > > > being clear what needs to be fixed. > > > > > > > > > > Isn't that the function of the text that was placed in section 8 of > > > > > > > > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 > > > > > > If it is not, then what do you think is missing. > > > > > > regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > > Behalf Of Cullen Jennings > > > > Sent: Tuesday, March 31, 2009 11:32 PM > > > > To: Jiri Kuthan > > > > Cc: sip@ietf.org; Francois Audet > > > > Subject: Re: [Sip] francois' comments and why RFC4474 not > > > > used in the field > > > > > > > > > > > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: > > > > > > > > > > > > > > I'm worried this is only a wishful thinking. While > > > > perfectly logical, > > > > > still even in such constrained setups some bizzar ALGs do in my > > > > > experience appear in the middle, change SDP and make thus > > > > the identity > > > > > worthless. > > > > > > > > The thing I keep asking is can we make a list of reason why > > > > SDP and headers get changes and in what scenarios they do > > > > this. I think it will be hard to sort how to fix this without > > > > being clear what needs to be fixed. > > > > > > > > For example, one of the things we might want to say is > > > > something like: > > > > the Phone is behind a NAT and connects to it's proxy / > > > > registrar for its' domain. That proxy/b2bua whatever mucks > > > > with IP/ports in the SDP for NAT traversal. Then we could ask > > > > if 4474 is broken in this case or not and what might be a > > > > good way of solving the problem of having UAs behind NATs. > > > > > > > > Cullen > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --0016367d6a3c1eaca404667f0ffa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In that scenario you have probably passed 6 SBC's :-)

=A0=A0=A0 = Enterprise A (SBC1) -> (SBC2) SP A (SBC3)->(SBC4) SP B (SBC5)-> (S= BC6) Enterprise B.

/Hans Erik van Elburg


On Wed, Apr 1, 2009 at 12:33 PM, Elwell,= John <john.elwell@siemens-enterprise.com> wrote:
I would like service providers to chip in here. Suppose I use service
providers to establish a call between two enterprises. Enterprise A uses SP A for all external traffic, and enterprise B uses SP B for all
external traffic. We then have a path:

=A0 =A0 =A0 =A0Enterprise A -> SP A -> SP B -> Enterprise B.

What I would like to know is whether SP A and/or SP B would have reason
to change the SDP (also other aspects of the SIP request, but just stick to SDP for now). If they need to change it, then what drives this need
to change the SDP: NAT traversal, topology hiding, media steering, ....?
If SPs think they have no reason to change SDP in such situations, then
this part of the problem is solved. However, I very much doubt that is
the case.

John


> -----Original Message-----
> From: sip-bounces@ietf.org= [mailto:sip-bounces@ietf.org] = On
> Behalf Of Cullen Jennings
> Sent: 01 April 2009 02:24
> To: DRAGE, Keith (Keith)
> Cc: sip@ietf.org; Francois Audet > Subject: Re: [Sip] francois' comments and why RFC4474 not
> used in the field
>
>
> In all of section 8, the only reason I find of why things are
> changed is
>
> "For media steering purposes, B2BUAs in intermediate domains need= to
> modify the IP address c-lines and the port in m-lines."
> Even this one line leaves me confused about what intermediate
> domains
> are in the deployment cases where this happens and if we are talking > about email style address or e.164 style addresses. What an
> example is
> of a deployment where things like this happen and why the
> middle (not
> the end domains) do the media steering. When I ask this of example
> people give me, if often turns out what is really wanted is
> not media
> steering but the middle to be able to hide the fact that they
> actually
> delivered the call to a third provider for PSTN termination.
>
> Pretend 4474 does not even exist for a minute. I don't think it is=
> unrealizable of me to ask what the problem is we are trying
> to solve.
> Saying 4474 is does not solve the problem may or may not be true but > we are unlikely to have a good conversation about about what
> we should
> do until we understand what we are trying to accomplish.
>
>
> On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote:
>
> > Cullen wrote:
> >
> > > The thing I keep asking is can we make a list of reason why<= br> > > > SDP and headers get changes and in what scenarios they do > > > this. I think it will be hard to sort how to fix this withou= t
> > > being clear what needs to be fixed.
> > >
> >
> > Isn't that the function of the text that was placed in sectio= n 8 of
> >
> >
> http://tools.ietf.org/html/draft-elwell-sip-e= 2e-identity-important-03
> >
> > If it is not, then what do you think is missing.
> >
> > regards
> >
> > Keith
> >
> > > -----Original Message-----
> > > From: sip-bounces@ie= tf.org [mailto:sip-bounces@ietf= .org] On
> > > Behalf Of Cullen Jennings
> > > Sent: Tuesday, March 31, 2009 11:32 PM
> > > To: Jiri Kuthan
> > > Cc: sip@ietf.org; Franco= is Audet
> > > Subject: Re: [Sip] francois' comments and why RFC4474 no= t
> > > used in the field
> > >
> > >
> > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote:
> > >
> > > >
> > > > I'm worried this is only a wishful thinking. While<= br> > > > perfectly logical,
> > > > still even in such constrained setups some bizzar ALGs = do in my
> > > > experience appear in the middle, change SDP and make th= us
> > > the identity
> > > > worthless.
> > >
> > > The thing I keep asking is can we make a list of reason why<= br> > > > SDP and headers get changes and in what scenarios they do > > > this. I think it will be hard to sort how to fix this withou= t
> > > being clear what needs to be fixed.
> > >
> > > For example, one of the things we might want to say is
> > > something like:
> > > the Phone is behind a NAT and connects to it's proxy / > > > registrar for its' domain. That proxy/b2bua whatever muc= ks
> > > with IP/ports in the SDP for NAT traversal. Then we could as= k
> > > if 4474 is broken in this case or not and what might be a > > > good way of solving the problem of having UAs behind NATs. > > >
> > > Cullen <in my individual contributor role>
> > >
> > > _______________________________________________
> > > Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Us= e
> > > sip-impl= ementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org= for new developments on the
> application of sip
> > >
>
> _______________________________________________
> Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implemento= rs@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new d= evelopments on the application of sip
>
_______________________________________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs= .columbia.edu for questions on current sip
Use sipping@ietf.org for new develo= pments on the application of sip

--0016367d6a3c1eaca404667f0ffa-- From fluffy@cisco.com Wed Apr 1 08:05:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6E73A6DE4 for ; Wed, 1 Apr 2009 08:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.627 X-Spam-Level: X-Spam-Status: No, score=-106.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbmhE2DVUCDA for ; Wed, 1 Apr 2009 08:05:09 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7ED313A6A98 for ; Wed, 1 Apr 2009 08:05:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="278133035" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2009 15:06:10 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n31F6Aj1009042; Wed, 1 Apr 2009 08:06:10 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n31F68Or016977; Wed, 1 Apr 2009 15:06:08 GMT From: Cullen Jennings To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> Impp: xmpp:cullenfluffyjennings@jabber.org References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> Message-Id: <90BEE480-5C62-47F5-B7E1-5EE089798623@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 09:06:07 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3317; t=1238598370; x=1239462370; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=9e5L3jPezJ/mbp+9QpxiiegPYyim55S2pkLZ7KUAgH8=; b=SgV6IQDRysXGDaXVnTRVzs6zJWNZNreAXzm0EkFldNjiWnSIvrK1l8HKVV J3K/Rwis/UbK3Spkmr6e56/y4UtaqwXOeQFllR7XgJ3fXekQaJt9fSvD1lV3 Tldb3lkdfR; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:05:10 -0000 On Apr 1, 2009, at 4:33 AM, Elwell, John wrote: > I would like service providers to chip in here. Suppose I use service > providers to establish a call between two enterprises. Enterprise A > uses > SP A for all external traffic, and enterprise B uses SP B for all > external traffic. We then have a path: > > Enterprise A -> SP A -> SP B -> Enterprise B. > > What I would like to know is whether SP A and/or SP B would have > reason > to change the SDP (also other aspects of the SIP request, but just > stick > to SDP for now). If they need to change it, then what drives this need > to change the SDP: NAT traversal, topology hiding, media > steering, ....? > > If SPs think they have no reason to change SDP in such situations, > then > this part of the problem is solved. However, I very much doubt that is > the case. > > John I think this is exactly the right sort of question to be asking (and we all agree they have reasons they are currently changing the SDP, what we need to get at is why). I think we also need to know about situations like > UA A -> SP A -> SP B -> UA B. Enterprise A -> SP A -> SP B -> SP C -> Enterprise B. And reasons SP B would change it. We also need to understand for each use case if it is an E.164 number or email style name. We need to deal with the cases where one of both of the ends is the PSTN not an enterprise. We also need to understand the trust relationships between the various entities. By that I mean things like "Enterprise B is willing to trust SP C (who it pays) will not misroute it calls". Or that UA A trust SP A not to give A's AOR to someone else. Then we need to go through use case and figure out which requirements derive the modification of key headers or bodies and which use cases happen in real deployments and which ones are purely hypothetical. They type of reasons for modification of headers/SDP that have been raised in past include things like topology hiding, media steering, nat traversal, and protocol repair. Next we need to work on what the problem is. This includes things like "I want to know who's phone I will be talking to if I answer this ringing call so I can decide if I answer the call" or "I want to know who's phone I am talking to at the other end so I can decide what I might say", or "I want to be able to reject all calls at 2am that are not from a phone that is listed in my personal address book". I'm not proposing any of these are the right problem statement - I'm just trying to give examples of they type of statement that if we agreed on it would help us make progress. We have proven over and ever again that without understanding what problem we are trying to fix, we don't get very far. Saying that the problem is "4474 does not work", does not help in the slightest. That may or may not be true but it is not the problem - it's a statement about if 4474 as a technology helps solve some unspecified problem or not. I have been advocating for years now that the discussion about if 4474 works for problem X or not is not going to get far without some agreement on what the various values of X are. Cullen From AUDET@nortel.com Wed Apr 1 08:11:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A68123A687C for ; Wed, 1 Apr 2009 08:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.29 X-Spam-Level: X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y79PiVWuV8P for ; Wed, 1 Apr 2009 08:11:45 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 085193A69AA for ; Wed, 1 Apr 2009 08:11:44 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n31FCbA20292; Wed, 1 Apr 2009 15:12:38 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 10:12:24 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D30567A@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmyaKIrc8L0E8LqT+OUkU6/Sj2JXAAROLSwAAuajdA= References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> A<0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Cullen Jennings" , "DRAGE, Keith (Keith)" Cc: sip@ietf.org Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:11:46 -0000 This is the wrong question to ask. If an Enteprise does NOT want a service provider to "muck around" with it's media, it will pick a service provider that does not, or use 4474 to ensure it doesn't happen. I would expect that smaller Enteprises (SMB/SME) might be=20 comfortable with a service provider that "adds value" by=20 mucking around with its media. Presumably for NAT/Firewall traversal reasons, willingness to be tapped into by the authorities, etc.=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Wednesday, April 01, 2009 03:34 > To: Cullen Jennings; DRAGE, Keith (Keith) > Cc: sip@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 > I would like service providers to chip in here. Suppose I use=20 > service providers to establish a call between two=20 > enterprises. Enterprise A uses SP A for all external traffic,=20 > and enterprise B uses SP B for all external traffic. We then=20 > have a path: >=20 > Enterprise A -> SP A -> SP B -> Enterprise B. >=20 > What I would like to know is whether SP A and/or SP B would=20 > have reason to change the SDP (also other aspects of the SIP=20 > request, but just stick to SDP for now). If they need to=20 > change it, then what drives this need to change the SDP: NAT=20 > traversal, topology hiding, media steering, ....? >=20 > If SPs think they have no reason to change SDP in such=20 > situations, then this part of the problem is solved. However,=20 > I very much doubt that is the case. >=20 > John >=20 >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of=20 > > Cullen Jennings > > Sent: 01 April 2009 02:24 > > To: DRAGE, Keith (Keith) > > Cc: sip@ietf.org; Francois Audet > > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the=20 > > field > >=20 > >=20 > > In all of section 8, the only reason I find of why things=20 > are changed=20 > > is > >=20 > > "For media steering purposes, B2BUAs in intermediate=20 > domains need to=20 > > modify the IP address c-lines and the port in m-lines." > > Even this one line leaves me confused about what=20 > intermediate domains=20 > > are in the deployment cases where this happens and if we=20 > are talking=20 > > about email style address or e.164 style addresses. What an=20 > example is=20 > > of a deployment where things like this happen and why the=20 > middle (not=20 > > the end domains) do the media steering. When I ask this of example=20 > > people give me, if often turns out what is really wanted is=20 > not media=20 > > steering but the middle to be able to hide the fact that=20 > they actually=20 > > delivered the call to a third provider for PSTN termination. > >=20 > > Pretend 4474 does not even exist for a minute. I don't think it is=20 > > unrealizable of me to ask what the problem is we are trying=20 > to solve. > > Saying 4474 is does not solve the problem may or may not be=20 > true but=20 > > we are unlikely to have a good conversation about about=20 > what we should=20 > > do until we understand what we are trying to accomplish. > >=20 > >=20 > > On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote: > >=20 > > > Cullen wrote: > > > > > > > The thing I keep asking is can we make a list of reason why SDP=20 > > > > and headers get changes and in what scenarios they do this. I=20 > > > > think it will be hard to sort how to fix this without=20 > being clear=20 > > > > what needs to be fixed. > > > > > > > > > > Isn't that the function of the text that was placed in=20 > section 8 of > > > > > >=20 > >=20 > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 > > > > > > If it is not, then what do you think is missing. > > > > > > regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org=20 > [mailto:sip-bounces@ietf.org] On Behalf=20 > > > > Of Cullen Jennings > > > > Sent: Tuesday, March 31, 2009 11:32 PM > > > > To: Jiri Kuthan > > > > Cc: sip@ietf.org; Francois Audet > > > > Subject: Re: [Sip] francois' comments and why RFC4474=20 > not used in=20 > > > > the field > > > > > > > > > > > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: > > > > > > > > > > > > > > I'm worried this is only a wishful thinking. While > > > > perfectly logical, > > > > > still even in such constrained setups some bizzar=20 > ALGs do in my=20 > > > > > experience appear in the middle, change SDP and make thus > > > > the identity > > > > > worthless. > > > > > > > > The thing I keep asking is can we make a list of reason why SDP=20 > > > > and headers get changes and in what scenarios they do this. I=20 > > > > think it will be hard to sort how to fix this without=20 > being clear=20 > > > > what needs to be fixed. > > > > > > > > For example, one of the things we might want to say is=20 > something=20 > > > > like: > > > > the Phone is behind a NAT and connects to it's proxy /=20 > registrar=20 > > > > for its' domain. That proxy/b2bua whatever mucks with=20 > IP/ports in=20 > > > > the SDP for NAT traversal. Then we could ask if 4474 is=20 > broken in=20 > > > > this case or not and what might be a good way of solving the=20 > > > > problem of having UAs behind NATs. > > > > > > > > Cullen > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the > > application of sip > > > > > >=20 > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 From fluffy@cisco.com Wed Apr 1 08:30:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87CA53A6DA6 for ; Wed, 1 Apr 2009 08:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.627 X-Spam-Level: X-Spam-Status: No, score=-106.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZUUWPmWnek2 for ; Wed, 1 Apr 2009 08:30:24 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BA5BC3A6DB5 for ; Wed, 1 Apr 2009 08:30:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="149465045" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 01 Apr 2009 15:30:52 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n31FUp5g023695; Wed, 1 Apr 2009 08:30:51 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n31FUoeQ008117; Wed, 1 Apr 2009 15:30:50 GMT From: Cullen Jennings To: Dean Willis In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: <49CE8255.4000103@iptel.org> Message-Id: <43884D59-CC27-466C-88B0-71EA723454DA@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 09:30:49 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4046; t=1238599851; x=1239463851; 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:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=bHhwJ4Ke5yi/jyfPHm/aMx3o67WASaeINA69ggOIirU=; b=e0ecjs7jgzWMQUBljNfqWFfsEqh6Ytkd4UgPxrcHZUKvcqjaKdk1Uzu2Qr 3SD6A6yNllewYp9bUei8PHdnCO9gP7PBdrWmd/oYpWVHHdtwhLBuKKP4bb65 n7ottFzlLu; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIP List Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:30:26 -0000 On Apr 1, 2009, at 12:52 AM, Dean Willis wrote: > > On Mar 31, 2009, at 5:31 PM, Cullen Jennings wrote: > >> >> On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: >> >>> >>> I'm worried this is only a wishful thinking. While perfectly >>> logical, still even in such constrained setups some bizzar >>> ALGs do in my experience appear in the middle, change SDP >>> and make thus the identity worthless. >> >> The thing I keep asking is can we make a list of reason why SDP and >> headers get changes and in what scenarios they do this. I think it >> will be hard to sort how to fix this without being clear what needs >> to be fixed. >> >> For example, one of the things we might want to say is something >> like: the Phone is behind a NAT and connects to it's proxy / >> registrar for its' domain. That proxy/b2bua whatever mucks with IP/ >> ports in the SDP for NAT traversal. Then we could ask if 4474 is >> broken in this case or not and what might be a good way of solving >> the problem of having UAs behind NATs. >> > > You seem to be trying to construct an argument for "why 4474 isn't > broken" based on being able to transform every use case where RFC > 4474 breaks to one where it doesn't, generally by mandating a > different approach to solving problems (TURN vs, SDP fixup, for > example). You seem to expect this to prove that RFC 4474 is fine as- > is, needing no modification to its A/M signing. No Dean. I am trying to get to what is the problem - and what I see happening is several people trying to transform that into Jon and Cullen are blocking work in this space which is not at all true - I would love to see some progress in this space. > > > It might be useful to counter this with "If RFC 4474 isn't broken, > why isn't it being deployed?" It's not needed in the bulk of todays deployments. Deployments using email stye addresses are directly connecting often with mutual TLS or an equivalently bound VPN. When enterprise B gets a call from fluffy@a.com and it came over a TLS connection that had a certificate of a.com, well you get something that meets B's authorization needs with just that. For deployments using E.164 style addresses - they are pretty much all capable of connecting in and out of the PSTN and there is no interest in a security properties greater than what PSTN provides as that is acceptable for most these users. This can easily be accomplished with PAI and a transitive trust model. In fact, many of these deployments have SP A talking to SP B talking to SP C and B explicitly wants to hide that they used SP C instead of terminating the call themselves. B needs to make it look like to A like B terminated the call into the PSTN vs handing it to C. These sort of deployments require B to look to A like the end not the middle. > I expect that the answer is "because users currently expect to > correct their topological issues using SBCs instead of the tools > that work with 4474. You might not think they have legitimate > reasons for doing it this way, but the fact remains -- that's how > they do it. You expect it might be one thing - fair enough, other disagree. What I am suggesting will be the best way to make progress is to find out what they do and what needs caused them to do it. Sure, for any problem, there will be multiple ways to skin the cat. You are accusing me of saying that the only way people are allowed to skin the cat is using a potato peeler and that most people probably will not use a potato peeler for cats no matter what I want. I am not in the slightest telling people they have to use a potato peeler - I'm arguing that until we have some common ground on if we are trying to peel a cat or potato or both, we are unlikely to make progress on the best tool(s) for the job. > Technically correct or not, ordering this to flow out is likely to > give you wet feet. > > -- > Dean > From mary.barnes@nortel.com Wed Apr 1 08:45:07 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1CC53A688F for ; Wed, 1 Apr 2009 08:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hKuW+dn2g1a for ; Wed, 1 Apr 2009 08:45:06 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 673953A67F7 for ; Wed, 1 Apr 2009 08:45:06 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n31FjS929642; Wed, 1 Apr 2009 15:45:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 10:48:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D3057CC@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001AAD91F@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt Thread-Index: AcmrCM6JQl7jVPxiTLCCOleoI30vAAAO9/JgAeb8KuA= References: <49C502AB.9040103@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001AAD91F@GBNTHT12009MSX.gb002.siemens.net> From: "Mary Barnes" To: "Elwell, John" , "Francois Audet" , "Jonathan Rosenberg" , "SIP IETF" , "Mary BARNES" , <"B601:EXCH]"@zcars04e.nortel.com> Subject: Re: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:45:07 -0000 Sorry for the delay in responding. You may need the indexing mechanism for some usages - e.g., for diagnostics to know the complete tree of visited nodes, "retargets", etc. Certainly, it's not needed for any of the examples in the target-uri document. And, again, as I stated in the SIP session, if we're going to trim down some of the original requirements (that we spent nearly 3 years debating) and solution (that we spent 2 years debating), we're really talking about something quite different in terms of functionality provided by History-Info. AND, this would introduce a backwards compatibility issue in some cases for folks that have implemented RFC 4244. And, in the end, we really would end up with something looking very much like the Diversion header. =20 Mary.=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Sunday, March 22, 2009 6:21 PM To: Audet, Francois (SC100:3055); Jonathan Rosenberg; SIP IETF; Mary BARNES; "B601:EXCH]"@zcars04e.nortel.com Subject: Re: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt Part of the complexity is in the indexing mechanism. Do we really need this? John=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 > Francois Audet > Sent: 22 March 2009 16:11 > To: Jonathan Rosenberg; SIP IETF; Mary BARNES;=20 > "B601:EXCH]"@zcars04e.nortel.com > Subject: Re: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt >=20 > Jonathan, you are correct, we have not done too many changes so far. > In part because we are waiting on target-URI, in part because we=20 > didn't have enough time. And mostly, because we'd like to get=20 > agreement on how to proceed before. I'd like to discuss in the=20 > meeting. >=20 > The problems with HI today, IMHO, are the following: >=20 > - In order to make it work, today, people make "assumptions"=20 > about HI to > be able to use it. Specifically, it is assumed that the first > retargeting is listed, and so are the 2 last ones. This is then > used by implementations as part of service logic and/or mapping to > PSTN information (Original Called Number, Redirecting Number, Last > Called Number). Unfortunately, HI (the spec) makes no such garantee: > current usage however does. Furthermore, it is assumed that there=20 > are > no recorded "routing" entries before the first one or between the=20 > last > retarget and the final contact. One "simplification" that I would=20 > like > to see is rules that makes the outcome predictable. First, I would=20 > like > to mandate that at a minimum those entries (first, last > two) are NEVER > removed by proxies, and second, that retargets proper are labeled as > such (as per target-URI discussion). That would greatly simplify > History-Info. >=20 > - There is a bug in ABNF. Corrected in current draft. >=20 > - There is a gratuitous requirement that TLS be used on each hop for > HI. I'd like to revisit that. Nobody enforces that, and I see no=20 > reason > why HI would be treated differently than other similar headers (Via, > Record-Route). >=20 > - The examples are all wrong... They are all using Strict Routing. The > chances of having an implementation using HI and Strict Routing in=20 > real > life are close to zero. It makes the reading more complex, and makes > HI look like some form of Record-Routing. >=20 > - There have been some editorial comments on text being repetitive and > wordy, and some proposals for simplification. >=20 > - Finally, and importantly, the idea would be to integrate all the > changes from target-URI, including the mid-path retarget (as per=20 > point > one above), and the last-Contact replacement. >=20 >=20 >=20 > On Mar21 2009 08:07 , "Jonathan Rosenberg" wrote: >=20 > > My main comment at this time, is that this bis document doesn't seem > > much different from the original. Section 10 calls out a > bunch of things > > that I would put in the 'minor' category - certainly not worth a=20 > > wholesale bis document if this is all we do. > >=20 > > I think it'd be worth having a high level discussion on the > changes we'd > > like to make to this document, and assess whether there are > enough to > > warrant a bis. For example, many have complained about the > complexity of > > HI; are there changes meant to help that? So far, frankly, the few=20 > > comments on this draft have been suggestions for additions > for the most > > part, and NOT simplifications. Is this meant as an omnibus > for a bunch > > of extensions to HI? > >=20 > > Thanks, > > Jonathan R. >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From timothy.dwight@verizon.com Wed Apr 1 09:04:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE073A6840 for ; Wed, 1 Apr 2009 09:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 YgQJSlSnR3SQ for ; Wed, 1 Apr 2009 09:04:48 -0700 (PDT) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id AFABD3A6956 for ; Wed, 1 Apr 2009 09:04:05 -0700 (PDT) Received: from omzismtp01.vzbi.com ([165.122.46.164]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHF00G85IV9EL00@firewall.verizonbusiness.com> for sip@ietf.org; Wed, 01 Apr 2009 15:54:46 +0000 (GMT) Received: from omzismtp01.vzbi.com ([127.0.0.1]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHF00E9XIV9GJ00@omzismtp01.vzbi.com> for sip@ietf.org; Wed, 01 Apr 2009 15:54:45 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([153.39.68.167]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHF00E7HIV7FG00@omzismtp01.vzbi.com> for sip@ietf.org; Wed, 01 Apr 2009 15:54:45 +0000 (GMT) Received: from ASHEVS015.vzbi.com ([153.39.71.98]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 01 Apr 2009 15:54:44 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Date: Wed, 01 Apr 2009 15:54:27 +0000 Message-id: In-reply-to: <90BEE480-5C62-47F5-B7E1-5EE089798623@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-index: Acmy227EUD3QE7BXRz2Lv9t5JY4fyAABHPow References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <90BEE480-5C62-47F5-B7E1-5EE089798623@cisco.com> From: "Dwight, Timothy M (Tim)" To: Cullen Jennings , "Elwell, John" X-OriginalArrivalTime: 01 Apr 2009 15:54:44.0536 (UTC) FILETIME=[2D134380:01C9B2E2] X-Mailman-Approved-At: Wed, 01 Apr 2009 09:13:31 -0700 Cc: sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:04:49 -0000 Cullen, These are "hotly debated" issues in the service provider community. I would hasten to say that nobody has appointed me to speak on that community's behalf. So the following views are my own. You stated: =20 > I think this is exactly the right sort of question to be asking (and =20 > we all agree they have reasons they are currently changing the SDP, =20 > what we need to get at is why). >=20 > I think we also need to know about situations like > > >=20 >=20 > UA A -> SP A -> SP B -> UA B. > Enterprise A -> SP A -> SP B -> SP C -> Enterprise B. >=20 > And reasons SP B would change it. I think the rationale for SP B changing the SDP is the same as SP A and C. It comes down to addressing. If their VoIP infrastructure is in a private address space, as it frequently is, then they need NAT and SIP ALG functionality at the edges of that space. Other issues such as topology hiding and media steering, are IMHO secondary in this debate. More fundamentally I wonder how a path through SP B would ever be constructed (assuming the arrows above refer to SIP flows). For sure you can do this with "policy routing" in SBCs, but using IETF preferred routing mechanisms (e.g., ENUM, RFC-3263) it's not clear to me what would motivate such routing. From AUDET@nortel.com Wed Apr 1 09:15:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D8B28C181 for ; Wed, 1 Apr 2009 09:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCHfK+8qx6PP for ; Wed, 1 Apr 2009 09:15:20 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 39C1E3A6949 for ; Wed, 1 Apr 2009 09:15:20 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n31GFM907957; Wed, 1 Apr 2009 16:15:22 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 11:15:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D305905@zrc2hxm0.corp.nortel.com> In-Reply-To: <042901c9b1b7$5f923a40$c4f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmxq9GNyI2jCsJzRPmmW+i4vP5uBQAC0NBQAEr+TMA= References: <49D17C20.8050907@cisco.com> <042901c9b1b7$5f923a40$c4f0200a@cisco.com> From: "Francois Audet" To: "Dan Wing" , "Jonathan Rosenberg" , "Jiri Kuthan" , "Cullen Jennings" , "Jon Peterson" Cc: SIP IETF , "Uzelac, Adam" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:15:21 -0000 So, having re-read all these drafts... Cullen/Jon, Why is something like draft-wing-sip-identity-media (let's focus just=20 on the DTLS-SRTP version for now) not a proper solution to the problem = we=20 are trying to solve?=20 The problem being (I think): Identity Assertion of both the Signalling and the Media, BUT allowing for relays? This has the advantage of being end-to-end. I guess the alternative is to not have end-to-end media identity assertion, and instead have = Alice-to- her-service-provider's relay, and Bob-to-his-service-provider's-relay=20 instead. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Monday, March 30, 2009 21:16 > To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'Jiri Kuthan' > Cc: 'SIP IETF'; 'Uzelac, Adam'; 'Dean Willis' > Subject: RE: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, March 30, 2009 7:53 PM > > To: Jonathan Rosenberg; Jiri Kuthan; Dan WING > > Cc: SIP IETF; Uzelac, Adam; Dean Willis > > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the=20 > > field > >=20 > > For everybody's reference, can you point to Dan's draft? >=20 > It is > http://tools.ietf.org/html/draft-wing-sip-identity-media-02 >=20 > other proposals in the same sphere, > http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00 > http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01 >=20 > -d >=20 >=20 > > On Mar30 2009 19:12 , "Jonathan Rosenberg"=20 > wrote: > >=20 > > > inline: > > >=20 > > > Jiri Kuthan wrote: > > >=20 > > >=20 > > >>> From an end user perspective, I would assert that the > > most important > > >>> thing is probably the media. If the callerID says, "this > > is bob", what > > >>> is important to the user, is that when I pick up the > > phone and start > > >>> talking, it will be Bob who hears me, and Bob that I hear. > > >>>=20 > > >>> Consider this litmus test: > > >>>=20 > > >>> If the signaling actually came from Mary (perhaps as a > > third party), > > >>> but the media goes/comes to/from Bob, who should appear > > on the caller > > >>> ID? I say - Bob. > > >>=20 > > >> There is a timing aspect in favor of placing identity in > > signaling -- > > >> I would like to know whose call is ringing before I answer > > (if I do). > > >=20 > > > You can still have that. Just don't ring the phone until > > early media has > > > been exchanged and verified. Indeed if you were doing an > > ICE-style thing > > > per Dan's draft, you'd get that for free. > > >=20 > > > -Jonathan R. > > >=20 > > >=20 > >=20 >=20 >=20 From dwing@cisco.com Wed Apr 1 10:16:52 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885C03A6840 for ; Wed, 1 Apr 2009 10:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: 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-R22bNy6E0A for ; Wed, 1 Apr 2009 10:16:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0B09F3A67B5 for ; Wed, 1 Apr 2009 10:16:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="149529349" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 01 Apr 2009 17:17:51 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n31HHpWd015535; Wed, 1 Apr 2009 10:17:51 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n31HHpaS028603; Wed, 1 Apr 2009 17:17:51 GMT From: "Dan Wing" To: "'Hans Erik van Elburg'" , "'Elwell, John'" References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> Date: Wed, 1 Apr 2009 10:17:50 -0700 Message-ID: <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acmy1YoCUK4wwQPtRXi9V8ll+qbaVAAF/gCA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6861; t=1238606271; x=1239470271; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=oq0koiwebmTjvBrf+2B5+Sg+tEmqWy99xtoDN73raQc=; b=ARHmKxO4wKdvUJC3eE5MrOXMLnWKmRyiwNu4bt/YFXPWEqNkZgMCESXUBz AaN4Xkt2T1jEbgN6dgG+BzmxeZ7Y4m8DGMq+GH0pptqBEIBa3o3PMymBSaf3 ks/kif5e1C; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:16:52 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hans Erik van Elburg > Sent: Wednesday, April 01, 2009 7:23 AM > To: Elwell, John > Cc: Cullen Jennings; sip@ietf.org; Francois Audet; DRAGE,Keith (Keith) > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > In that scenario you have probably passed 6 SBC's :-) > > Enterprise A (SBC1) -> (SBC2) SP A (SBC3)->(SBC4) SP B > (SBC5)-> (SBC6) Enterprise B. And I doubt that every VoIP SP will be meshed with every other VoIP SP. So in many situations there will be a transit SP or two along the path. The PSTN has transit service providers (my local phone company is not directly connected with the phone company in Syria or India), and the Internet has transit service providers (some little ISP in Wyoming is not directly connected with a little ISP in Switzerland). -d > /Hans Erik van Elburg > > > > On Wed, Apr 1, 2009 at 12:33 PM, Elwell, John > wrote: > > > I would like service providers to chip in here. Suppose > I use service > providers to establish a call between two enterprises. > Enterprise A uses > SP A for all external traffic, and enterprise B uses SP > B for all > external traffic. We then have a path: > > Enterprise A -> SP A -> SP B -> Enterprise B. > > What I would like to know is whether SP A and/or SP B > would have reason > to change the SDP (also other aspects of the SIP > request, but just stick > to SDP for now). If they need to change it, then what > drives this need > to change the SDP: NAT traversal, topology hiding, > media steering, ....? > > If SPs think they have no reason to change SDP in such > situations, then > this part of the problem is solved. However, I very > much doubt that is > the case. > > John > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Cullen Jennings > > > Sent: 01 April 2009 02:24 > > To: DRAGE, Keith (Keith) > > Cc: sip@ietf.org; Francois Audet > > Subject: Re: [Sip] francois' comments and why RFC4474 not > > used in the field > > > > > > In all of section 8, the only reason I find of why things are > > changed is > > > > "For media steering purposes, B2BUAs in intermediate > domains need to > > modify the IP address c-lines and the port in m-lines." > > Even this one line leaves me confused about what intermediate > > domains > > are in the deployment cases where this happens and if > we are talking > > about email style address or e.164 style addresses. What an > > example is > > of a deployment where things like this happen and why the > > middle (not > > the end domains) do the media steering. When I ask > this of example > > people give me, if often turns out what is really wanted is > > not media > > steering but the middle to be able to hide the fact that they > > actually > > delivered the call to a third provider for PSTN termination. > > > > Pretend 4474 does not even exist for a minute. I > don't think it is > > unrealizable of me to ask what the problem is we are trying > > to solve. > > Saying 4474 is does not solve the problem may or may > not be true but > > we are unlikely to have a good conversation about about what > > we should > > do until we understand what we are trying to accomplish. > > > > > > On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote: > > > > > Cullen wrote: > > > > > > > The thing I keep asking is can we make a list of > reason why > > > > SDP and headers get changes and in what scenarios they do > > > > this. I think it will be hard to sort how to fix > this without > > > > being clear what needs to be fixed. > > > > > > > > > > Isn't that the function of the text that was placed > in section 8 of > > > > > > > > > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 > > > > > > If it is not, then what do you think is missing. > > > > > > regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On > > > > Behalf Of Cullen Jennings > > > > Sent: Tuesday, March 31, 2009 11:32 PM > > > > To: Jiri Kuthan > > > > Cc: sip@ietf.org; Francois Audet > > > > Subject: Re: [Sip] francois' comments and why RFC4474 not > > > > used in the field > > > > > > > > > > > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: > > > > > > > > > > > > > > I'm worried this is only a wishful thinking. While > > > > perfectly logical, > > > > > still even in such constrained setups some > bizzar ALGs do in my > > > > > experience appear in the middle, change SDP and > make thus > > > > the identity > > > > > worthless. > > > > > > > > The thing I keep asking is can we make a list of > reason why > > > > SDP and headers get changes and in what scenarios they do > > > > this. I think it will be hard to sort how to fix > this without > > > > being clear what needs to be fixed. > > > > > > > > For example, one of the things we might want to say is > > > > something like: > > > > the Phone is behind a NAT and connects to it's proxy / > > > > registrar for its' domain. That proxy/b2bua whatever mucks > > > > with IP/ports in the SDP for NAT traversal. Then > we could ask > > > > if 4474 is broken in this case or not and what might be a > > > > good way of solving the problem of having UAs behind NATs. > > > > > > > > Cullen > > > > > > > > _______________________________________________ > > > > Sip mailing list > https://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP > Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > Use sipping@ietf.org for new developments on the > application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sipping@ietf.org for new developments on the > application of sip > > > > From christer.holmberg@ericsson.com Wed Apr 1 10:26:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3163A6B84 for ; Wed, 1 Apr 2009 10:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.804 X-Spam-Level: X-Spam-Status: No, score=-5.804 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCfHCrOUG131 for ; Wed, 1 Apr 2009 10:26:23 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E847E3A6B6F for ; Wed, 1 Apr 2009 10:26:22 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB2E920573; Wed, 1 Apr 2009 19:27:21 +0200 (CEST) X-AuditID: c1b4fb3e-affbdbb000006d6d-e9-49d3a3f9f72c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C2FEF20275; Wed, 1 Apr 2009 19:27:21 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 19:26:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 19:26:35 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D267EBE@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of draft-holmberg-sip-keep Thread-Index: Acmw6zKd0889sHT5RxuRDPO+WEUpCAAbiqdQAAD4FLA= References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> <81881C2E-C631-4F46-A506-C984248337DC@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D267EBE@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Dean Willis" , "Mary Barnes" X-OriginalArrivalTime: 01 Apr 2009 17:26:36.0036 (UTC) FILETIME=[022F6C40:01C9B2EF] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, Cullen Jennings Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:26:24 -0000 Hi, I agree with Francois. People have been waiting a long time for Outbound, so let's not delay it (and keep) further. Regards, Christer=20 -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Monday, March 30, 2009 8:10 PM To: Dean Willis; Mary Barnes Cc: sip@ietf.org; Christer Holmberg; Cullen Jennings Subject: RE: [Sip] New version of draft-holmberg-sip-keep Dean,=20 There is no reason to do so. There is no "similar but not identical text" in draft-keep. Draft-keep only defines a parameter that allows the usage of the keep-alive defined in draft-ietf-sip-outbound, outside of the context of the registration procedures of draft-ietf-sip-outbound.=20 Currently, the two drafts are carefully choregraphed to be consistent. I don't want to undo this at the last minute. Note that some other drafts in the queue are dependent on draft-ietf-outbound (e.g., draft-ietf-sip-sips). I really don't want us to undo our work for no good reason. I would recommend moving draft-keep swiftly to WG document. I believe it should rapidly move into last call. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 > Dean Willis > Sent: Sunday, March 29, 2009 20:54 > To: Barnes, Mary (RICH2:AR00) > Cc: sip@ietf.org; Christer Holmberg > Subject: Re: [Sip] New version of draft-holmberg-sip-keep >=20 >=20 > On Mar 26, 2009, at 6:16 PM, Mary Barnes wrote: >=20 > > Hi folks, > > > > Christer has updated the document based on the action item from=20 > > Wednesday's SIP session (chaired by SIPPING chairs and > modeled as the > > proposed DISPATCH WG). If folks could please review the > document and > > raise any concerns on the document now, that would be > appreciated. We > > ask specifically for an answer to the question: Do you support the=20 > > document being adopted as a WG document in RAI (WG tbd)? A simple=20 > > "yes" is fine, however, if you don't think we should adopt this=20 > > document, could you please provide the reason. > > > > > > >=20 > So, given the outpouring of support, should we pull back the > draft- ietf-sip-outbound and re-write it to refer to the keepalive=20 > mechanism of this draft instead of containing similar but not=20 > identical text? >=20 > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 From dean.willis@softarmor.com Wed Apr 1 10:35:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC713A6DB7 for ; Wed, 1 Apr 2009 10:35:40 -0700 (PDT) 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 bRA-I-q1kELr for ; Wed, 1 Apr 2009 10:35:39 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9E1893A67B5 for ; Wed, 1 Apr 2009 10:35:39 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n31HaRBx026017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2009 12:36:29 -0500 Message-Id: <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> From: Dean Willis To: "Dwight, Timothy M (Tim)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 12:36:22 -0500 References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.930.3) Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" , Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:35:40 -0000 On Apr 1, 2009, at 9:09 AM, Dwight, Timothy M (Tim) wrote: > John, > > In my experience, service providers (such as the one I work for) > sometimes change the SDP in situations like this, and sometimes don't. > It depends on whether the service providers' VoIP infrastructure is in > the public Internet address space, or a private address space (e.g., > MPLS/BGP -based VPN). Use of the latter configuration requires NAT > and > SIP ALG functionality "at the edge". In the diagram below there is an > "edge" everywhere you draw an arrow. Typically the devices that > implement the NAT and SIP ALG functions do other things, like topology > hiding and steering the media to a device that will then monitor > ("police") its arrival rate. One might argue that we know how to do NAT without ALG -- we use ICE to discover candidates for the offer/answer, and the media finds the path that works using STUN probes. Could we use ICE to get to the steering points? Do we really need them, or is this just a brute-force way to solve a problem to which other tools should have been applied? Topology-hiding is another question. Does it benefit the Internet architecture? Do we need to warp our protocols to allow it? > > Alternatively, if the SP's infrastructure is in the public address > space, you typically don't see NAT / SIP ALG or topology hiding or > media > steering. You may (often do) still see "border devices" doing things > like traffic aggregation and policy based routing. > Do we need SDP editing to allow these functions, or is there a cleaner way to do it? > In either case, it's not uncommon that the border elements modify > other > aspects of the SIP signaling for reasons of interoperability. For > example it's sometimes [believed to be] necessary to modify response > codes due to differing implementations - e.g., to break an > infinite-retry loop. Do such modifications break RFC 4474? -- Dean From dean.willis@softarmor.com Wed Apr 1 10:47:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE9F3A6DCB for ; Wed, 1 Apr 2009 10:47:15 -0700 (PDT) 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 dnEhCwMPXyoX for ; Wed, 1 Apr 2009 10:47:15 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 06CC93A6DAF for ; Wed, 1 Apr 2009 10:47:14 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n31Hko5H026134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2009 12:46:51 -0500 Message-Id: <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> From: Dean Willis To: Dan Wing In-Reply-To: <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 12:46:45 -0500 References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:47:15 -0000 On Apr 1, 2009, at 12:17 PM, Dan Wing wrote: > > And I doubt that every VoIP SP will be meshed with every other VoIP > SP. So in > many situations there will be a transit SP or two along the path. > The PSTN > has transit service providers (my local phone company is not directly > connected with the phone company in Syria or India), and the > Internet has > transit service providers (some little ISP in Wyoming is not directly > connected with a little ISP in Switzerland). But the transit ISP should be routing the packets using their source and destination IP addresses, not mucking about in the application protocol. If some backbone ISP started putting in transparent HTTP proxies that diverted Web traffic to alternate sites, we'd have a "peasants with torches" scenario. Same for most of the media-steering cases: The traffic is IP. Route it like IP traffic and stop pretending to be a circuit switched phone! Doing application-sensitive packet routing is a direct path to chaos and unmanageable operational complexity. Or maybe we should have just defined SIP-over-MPLS and left out the whole IP middle layer? -- Dean From dwing@cisco.com Wed Apr 1 10:59:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657703A6C83 for ; Wed, 1 Apr 2009 10:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.638 X-Spam-Level: X-Spam-Status: No, score=-6.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lufMK27rfL-P for ; Wed, 1 Apr 2009 10:59:19 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5654A3A6A98 for ; Wed, 1 Apr 2009 10:59:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="149208047" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 01 Apr 2009 18:00:20 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n31I0JvV003461; Wed, 1 Apr 2009 11:00:19 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n31I0Jw8011506; Wed, 1 Apr 2009 18:00:19 GMT From: "Dan Wing" To: "'Dean Willis'" References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> Date: Wed, 1 Apr 2009 11:00:19 -0700 Message-ID: <038701c9b2f3$b88300c0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acmy8ght7aK+ey+1RPCLCGZ+IOxxfgAAT+Jg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2221; t=1238608819; x=1239472819; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=E90PK8/JGZgDEyNtRRw3RhzYTlJG+fk5mLPszfeG8ak=; b=YUbDgMJAg+RZlFkvD0EZD/EfV2qltKZgun3/E6d409VjbT0BuuONftl2Wv DLU8+c7c+vJ0/l58m4SqeBvjl3svfiWymWvtrHvYK3NPLDIOEgFBCAw16vBR Bz/VSARQts; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:59:20 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, April 01, 2009 10:47 AM > To: Dan Wing > Cc: 'Hans Erik van Elburg'; 'Elwell, John'; 'Cullen > Jennings'; sip@ietf.org; 'Francois Audet'; 'DRAGE, Keith (Keith)' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > On Apr 1, 2009, at 12:17 PM, Dan Wing wrote: > > > > > And I doubt that every VoIP SP will be meshed with every > other VoIP > > SP. So in > > many situations there will be a transit SP or two along the path. > > The PSTN > > has transit service providers (my local phone company is > not directly > > connected with the phone company in Syria or India), and the > > Internet has > > transit service providers (some little ISP in Wyoming is > not directly > > connected with a little ISP in Switzerland). > > But the transit ISP should be routing the packets using their source > and destination IP addresses, not mucking about in the application > protocol. The transit SIP provider has every interest in hiding the IP addresses of their own equipment and of the actual peers. Otherwise, the peers may make their own business agreement and circumvent the 'service' being provided by the transit SIP provider -- or so the argument goes. > If some backbone ISP started putting in transparent HTTP > proxies that diverted Web traffic to alternate sites, we'd have a > "peasants with torches" scenario. Using that analogy, if we were using RFC4474 with HTTPS we would all have to trust our service providers (Comcast, etc.) to reliably deliver our credit card and banking information to transit providers and finally to our bank or catalog ordering company. > Same for most of the media-steering cases: The traffic is IP. > Route it > like IP traffic and stop pretending to be a circuit switched phone! > > Doing application-sensitive packet routing is a direct path to chaos > and unmanageable operational complexity. > > Or maybe we should have just defined SIP-over-MPLS and left out the > whole IP middle layer? Acme Packet supports routing over MPLS networks. -d From pkyzivat@cisco.com Wed Apr 1 11:37:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BE273A6BE4 for ; Wed, 1 Apr 2009 11:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIRnnCf0vanA for ; Wed, 1 Apr 2009 11:37:13 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0C6623A6A6C for ; Wed, 1 Apr 2009 11:37:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="40721748" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Apr 2009 18:38:13 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n31IcDwM031387; Wed, 1 Apr 2009 14:38:13 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n31IcDCL026237; Wed, 1 Apr 2009 18:38:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 14:38:13 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 14:38:12 -0400 Message-ID: <49D3B493.4050101@cisco.com> Date: Wed, 01 Apr 2009 14:38:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dan Wing References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> In-Reply-To: <038701c9b2f3$b88300c0$c4f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2009 18:38:12.0637 (UTC) FILETIME=[0328B4D0:01C9B2F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=727; t=1238611093; x=1239475093; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20 |To:=20Dan=20Wing=20; bh=ritnlr0ShltWaSZhX/v8Ev50VLdF9t2iU0IL6B1nfTc=; b=KYb1WlUxEKi2wEkme1hjGATXJQz+Bq6hizMPgcayFufkhqxyxASsh+deZf MnGE7ZSsGDrUOW9ABzJPrcv5nUnyMNRlpQCJH0muyqA96rjGB4/AWoDRB3kk znEVnJ7KiX; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:37:16 -0000 Dan Wing wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> But the transit ISP should be routing the packets using their source >> and destination IP addresses, not mucking about in the application >> protocol. > > The transit SIP provider has every interest in hiding the IP addresses > of their own equipment and of the actual peers. Otherwise, the peers > may make their own business agreement and circumvent the 'service' > being provided by the transit SIP provider -- or so the argument > goes. If the peers can circumvent the SP and make their own business agreement, then perhaps the SP wasn't actually providing a service. Paul From HKaplan@acmepacket.com Wed Apr 1 11:38:01 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFFF93A6AB0 for ; Wed, 1 Apr 2009 11:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 WzI4UGuVSB0v for ; Wed, 1 Apr 2009 11:38:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6DC853A6DF6 for ; Wed, 1 Apr 2009 11:37:43 -0700 (PDT) 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.340.0; Wed, 1 Apr 2009 14:38:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 1 Apr 2009 14:38:43 -0400 From: Hadriel Kaplan To: Dean Willis , Dan Wing Date: Wed, 1 Apr 2009 14:38:42 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmy8hZ07FVa0dkmSK6kg/cFtrU+SwAAYw9g Message-ID: References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> In-Reply-To: <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> 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 Cc: 'Cullen Jennings' , "sip@ietf.org" , 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:38:02 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dea= n > Willis > Sent: Wednesday, April 01, 2009 1:47 PM >=20 > But the transit ISP should be routing the packets using their source > and destination IP addresses, not mucking about in the application > protocol. If some backbone ISP started putting in transparent HTTP > proxies that diverted Web traffic to alternate sites, we'd have a > "peasants with torches" scenario. That's not analogous and you know it, I think. We're not talking about a t= ransparent inline IP-layer ISP mucking about in the application layer. You= 're setting the SIP request URI host portion to your local provider, not th= e far-end (because you almost never know the far-end domain, and even if yo= u did they won't accept your request directly). Your SIP request really do= es almost always reach the local provider identified by that URI domain dir= ectly first. Being authoritative for that domain, they then route your req= uest to another domain, and so on, to reach an entity ultimately identified= by a phone number not a hostname. For another, you know and I know that w= eb-based communication is not like phone communication. In many ways SIP i= s much closer to IM or Email than HTTP, except it sometimes also costs mone= y. -hadriel From HKaplan@acmepacket.com Wed Apr 1 11:38:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E803A6DF2 for ; Wed, 1 Apr 2009 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 6IC-8HL2H8VA for ; Wed, 1 Apr 2009 11:38:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B6B1B3A6E02 for ; Wed, 1 Apr 2009 11:37:43 -0700 (PDT) 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.340.0; Wed, 1 Apr 2009 14:38:44 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 1 Apr 2009 14:38:44 -0400 From: Hadriel Kaplan To: Dean Willis , "Dwight, Timothy M (Tim)" Date: Wed, 1 Apr 2009 14:38:43 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmy8G2TLjlBD5+ARDuM5FrJjEPNjAABrqzA Message-ID: References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> In-Reply-To: <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> 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 Cc: Cullen Jennings , "sip@ietf.org" , Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:38:02 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dea= n > Willis > Sent: Wednesday, April 01, 2009 1:36 PM > To: Dwight, Timothy M (Tim) > > One might argue that we know how to do NAT without ALG -- we use ICE > to discover candidates for the offer/answer, and the media finds the > path that works using STUN probes. ICE can't find such candidates in some cases, as I've stated before on this= mailing list. The problem is the candidates need to change based on where= the call gets routed to. Not to mention there may never be a single publi= cly reachable IP used in the media path. > Topology-hiding is another question. Does it benefit the Internet > architecture? Do we need to warp our protocols to allow it? The question may be more: do we need to make our protocols disallow it? > Do we need SDP editing to allow these functions, or is there a cleaner > way to do it? Define "cleaner". Do you mean simpler, or do you mean more architecturally= pure from the IAB's perspective? The two are probably mutually exclusive.= :) > Do such modifications break RFC 4474? Yes, and they've been documented and discussed before, ad nauseam. Virtual= ly every piece of the message signed by 4474 is mucked with by some device = or other, with the exception of the Date header. -hadriel From christer.holmberg@ericsson.com Wed Apr 1 12:15:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104C03A6C83 for ; Wed, 1 Apr 2009 12:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.808 X-Spam-Level: X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETqT92FJfuwA for ; Wed, 1 Apr 2009 12:14:59 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 400A63A6829 for ; Wed, 1 Apr 2009 12:14:59 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 68F8C20A71; Wed, 1 Apr 2009 21:15:58 +0200 (CEST) X-AuditID: c1b4fb3c-acf95bb0000004b9-d5-49d3bd6e6910 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4470420A54; Wed, 1 Apr 2009 21:15:58 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 21:15:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 21:15:01 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmy8G2TLjlBD5+ARDuM5FrJjEPNjAABrqzAAAGz9WA= References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net><32590116-67B7-4C23-8159-7991372972EF@softarmor.com> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Dean Willis" , "Dwight, Timothy M (Tim)" X-OriginalArrivalTime: 01 Apr 2009 19:15:02.0712 (UTC) FILETIME=[28776380:01C9B2FE] X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:15:00 -0000 >Yes, and they've been documented and discussed before, ad nauseam. Virtually every piece of the message signed by 4474=20 >is mucked with by some device or other, with the exception of the Date header. Actually, some SPs don't allow people to make calls from the future, so if someone is using a future Date header value there may be an SBC which modifies that also ;) Regards, Christer From dwing@cisco.com Wed Apr 1 13:13:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B31A3A6B6A for ; Wed, 1 Apr 2009 13:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.634 X-Spam-Level: X-Spam-Status: No, score=-6.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGBWVrfLOxnd for ; Wed, 1 Apr 2009 13:13:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9976A3A672F for ; Wed, 1 Apr 2009 13:13:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,308,1235952000"; d="scan'208";a="149612131" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 01 Apr 2009 20:14:41 +0000 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 n31KEfix002471; Wed, 1 Apr 2009 13:14:41 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n31KEfYq019906; Wed, 1 Apr 2009 20:14:41 GMT From: "Dan Wing" To: "'Paul Kyzivat'" References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> Date: Wed, 1 Apr 2009 13:14:40 -0700 Message-ID: <040b01c9b306$7d1c1d60$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49D3B493.4050101@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acmy+QqH0+zhIov5S/qYKhIFb5s1sQADIINQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=757; t=1238616881; x=1239480881; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=nRSagxuhjgISFMVZ0lCeYt5mVjlk8qu5IkrcToqJomk=; b=chhp5M+pZgI5zM8cJRwjECGYQTv7mj26n8Rzn1qE326sPDilTcDM0JdXTq GP66GP6raIRepzfTo14NSdkSvcXjg6H7i6B7Kvf2UX8Qc5CZGCC9NOtRMjIO KjFWGSXfoPC5eUkAnXvejRFDj6SouSEVfez7UoQzvnHtokWOWjDao=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:13:41 -0000 > > The transit SIP provider has every interest in hiding the > > IP addresses > > of their own equipment and of the actual peers. Otherwise, > > the peers > > may make their own business agreement and circumvent the 'service' > > being provided by the transit SIP provider -- or so the argument > > goes. > > If the peers can circumvent the SP and make their own business > agreement, then perhaps the SP wasn't actually providing a service. There continue to be transit IP providers even though the Internet has been around for decades, and there continue to be transit PSTN providers even though the PSTN has been around for generations. We need an identity architecture that acknowledges transit and works with transit. -d From timothy.dwight@verizon.com Wed Apr 1 14:40:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D1D3A68AA for ; Wed, 1 Apr 2009 14:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 pf7P3WNEpt7h for ; Wed, 1 Apr 2009 14:40:57 -0700 (PDT) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id 426AA3A6863 for ; Wed, 1 Apr 2009 14:40:57 -0700 (PDT) Received: from omzismtp02.vzbi.com ([165.122.46.167]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHF0079TYWCKQ00@firewall.verizonbusiness.com> for sip@ietf.org; Wed, 01 Apr 2009 21:41:01 +0000 (GMT) Received: from omzismtp02.vzbi.com ([127.0.0.1]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHF00L49YWCIR00@omzismtp02.vzbi.com> for sip@ietf.org; Wed, 01 Apr 2009 21:41:00 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([153.39.68.167]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHF00L5CYWBG300@omzismtp02.vzbi.com> for sip@ietf.org; Wed, 01 Apr 2009 21:41:00 +0000 (GMT) Received: from ASHEVS015.vzbi.com ([153.39.71.98]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 01 Apr 2009 21:40:59 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Date: Wed, 01 Apr 2009 21:40:29 +0000 Message-id: In-reply-to: <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-index: Acmy8HDJf52wpBfbT66T8gh6Nf44xAAIP0NA References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> From: "Dwight, Timothy M (Tim)" To: Dean Willis X-OriginalArrivalTime: 01 Apr 2009 21:40:59.0708 (UTC) FILETIME=[8C0AEFC0:01C9B312] Cc: Cullen Jennings , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:40:58 -0000 Dean, Hadriel has answered most of your questions. On this point: > > Alternatively, if the SP's infrastructure is in the public address > > space, you typically don't see NAT / SIP ALG or topology hiding or media > > steering. You may (often do) still see "border devices" doing things > > like traffic aggregation and policy based routing. > > >=20 > Do we need SDP editing to allow these functions, or is there=20 > a cleaner way to do it? Sorry I wasn't more clear. These functions don't involve SDP editing. Traffic aggregation (by which I mean to refer to aggregation of SIP signaling traffic) is usually done with ROUTE headers or use of the 'maddr' URI parameter, or (most often) through re-targetting in the border device. Policy routing is some mechanism internal to the border device, that it uses to determine how to modify and to where to forward, the SIP message. tim From munjo.yu@gmail.com Wed Apr 1 18:16:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F00A3A6B69; Wed, 1 Apr 2009 18:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.927, 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 TOdO1v8AvL1c; Wed, 1 Apr 2009 18:16:58 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 3D9AF3A67F2; Wed, 1 Apr 2009 18:16:58 -0700 (PDT) Received: by qyk36 with SMTP id 36so663430qyk.29 for ; Wed, 01 Apr 2009 18:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=2AUfstrkdKl57zFGqfYQR7iOMFLyuHb8icozupQ21jQ=; b=HgK8HiUCDx9YzcvWkg51BVIZBEVq4EXrFLWU39zYCWYWEXHyvfXKSN73Hyu2ZugBIh OgyTFios58jx63LLuf11xl6phTWugsZkuYqZYbSOnY3qOmj8TZU3HvgY8zZrXWuWB+hO pVEpGHZ/o0bTwQ2tsqI/vWlJy/NpqAg3GOqcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=d9b2wZqxGFVhoxwLoORNMqGgEvH0oHTWZP7q/JpEASTjlQZ3zeoATwnPTEgzV2Z8yb JP9sJFt5kKrrq8fwkTLyHuuAOZ2ZgZAsxIx7Y89npMn2znOy8n3CVCsWOzj4qKTubvUI XVJO3kvt5ocZrd+5C8h7f067BM0YdpIRFjewI= MIME-Version: 1.0 Received: by 10.229.96.13 with SMTP id f13mr3357038qcn.36.1238635078798; Wed, 01 Apr 2009 18:17:58 -0700 (PDT) Date: Wed, 1 Apr 2009 20:17:58 -0500 Message-ID: From: Munjo Yu To: apps-discuss@ietf.org, sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jskim@vinegen.com Subject: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:16:59 -0000 Hi all, I am Munjo Yu and currently working with Jong Sung Kim of a network solution start-up in Korea, VineGen Inc. During the 74th IETF in San Francisco, Dave Crocker and Lisa Dusseault suggested us to post in the Application mailing list. And I thought the SIP mailing list is a good place too, since we have a use case of our extension with SIP. Jong Sung Kim noticed there should be a better version of the ABNF definition section of RFC 3261 while developing a "complete" ABNF parser generator. The parser generator is complete in the sense that generated parser code does not need any hand coding. In Section 7 of RFC 3261, Request is defined like following. Request = Request-Line *( message-header ) CRLF [ message-body ] where, message-header = (Accept / Accept-Encoding . / Call-ID . / CSeq . / Via . / extension-header) CRLF I omitted most part of the long "message-header" for sake of readability. >From the above, one can tell that *(message-header) achieves a group whose elements are non-sequential and optional. So, any of the following complies with the definition. () ; empty group (Accept) (Accept, Accept) (Accept, Call-ID) (Call-ID, Accept) and so on. However, only a small portion of all the possible combinations are legitimate according to some sections like 8.1.1 as follows. 8.1.1 Generating the Request A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, . . As shown above, few elements like To, From, CSeq, are mandatory - the first sign that the ABNF definition is not self-contained. In fact, all the "additional" definitions of message-header are embedded in various sections in the RFC , which makes it impractical ( if not impossible ) to build a complete parser generator. So, Jong Sung Kim had to add an extension, "non-sequential" group to ABNF, and he named it as SET whose is already available elsewhere like ASN.1 SET is described simply as follows, using a pair of braces: SET {Rule1 Rule2} Using SET, a redefinition of the above Request is something like following: Request = Request-Line message-header CRLF [ message-body ] where, message-header = { Call-ID CSeq . 1*Via . 0*1Accept 0*1Accept-Encoding . 0*1extension-header} CRLF This new version makes quite a few parts of the RFC paragraphs unnecessary and redundant, resulting in a self-contained, straightforward, easy-to-maintain, and parser generator friendly definition. We'd like to know what SIP folks would think about this, and if there are other cases that can benefit from this extension. Also would like to hear from App folks, such as balance between feature and simplicity, architectural point, etc. Regards, -Munjo Yu P.S. we'd like to express our thanks to Dave Crocker and Lisa Dusseault, and other WG chairs for their help and kindness during the meeting. From SRS0=ctsviW=AA=standardstrack.com=eburger@srs.bis.na.blackberry.com Wed Apr 1 18:25:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98403A685D; Wed, 1 Apr 2009 18:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.708 X-Spam-Level: X-Spam-Status: No, score=-6.708 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zau17Hky+2eE; Wed, 1 Apr 2009 18:25:34 -0700 (PDT) Received: from smtp01.bis.na.blackberry.com (smtp01.bis.na.blackberry.com [216.9.248.48]) by core3.amsl.com (Postfix) with ESMTP id 90B753A6821; Wed, 1 Apr 2009 18:25:33 -0700 (PDT) Received: from bda379.bisx.prod.on.blackberry (bda379.bisx.prod.on.blackberry [172.20.234.79]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id n321Qs5g031039; Thu, 2 Apr 2009 01:26:54 GMT Received: from bda379.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda379.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id n321QVYw021862; Thu, 2 Apr 2009 01:26:31 GMT X-rim-org-msg-ref-id: 858250208 Message-ID: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: In-Reply-To: Sensitivity: Normal Importance: Normal To: apps-discuss@ietf.org, SIP@ietf.org From: "eburger" Date: Thu, 2 Apr 2009 01:26:51 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: eburger@standardstrack.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 02:00:28 -0000 UGVyc29uYWxseSwgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB3ZSBkaWRuJ3QganVzdCB1c2UgWUFD Qy4gSSBhbSByZWFsbHkgaW4gZmF2b3Igb2YgdXNpbmcgYSBmb3JtYWwgbGFuZ3VhZ2UgZm9yIHNw ZWNpZnlpbmcgZ3JhbW1hci4gQXMgTXVuam8gc3RhdGVzLCB0aGUgQUJORiBpcyBlc3NlbnRpYWxs eSBkb2N1bWVudGF0aW9uIGZsdWZmIC0gdXNlbGVzcyBhdCBiZXN0IGFuZCB3cm9uZyBhdCB3b3Jz dC4gDQoNCkFzIGZvciB0aGlzIHBhcnRpY3VsYXIgc3VnZ2VzdGlvbiwgSSBhbSBhbWJpdmFsZW50 IGFzIHRvIHdoZXRoZXIgd2UgaGFjayBBQk5GLCBhZG9wdCBZQUNDLCBvciBldmVuIGFkb3B0IEFT Ti4xLiANCg0KLS0NCkVyaWMgQnVyZ2VyDQoNClNlbnQgZnJvbSBteSBtb2JpbGUgZGV2aWNlOyBz b3JyeSBpZiB0ZXJzZS4gQWxsIG1vYmlsZSB1c2VycyBuZWVkIGxlbW9uYWRlLiAgU2VlIDxodHRw Oi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlPiBmb3IgbW9yZSBpbmZvcm1h dGlvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE11bmpvIFl1IDxtdW5q by55dUBnbWFpbC5jb20+DQoNCkRhdGU6IFdlZCwgMSBBcHIgMjAwOSAyMDoxNzo1OCANClRvOiA8 YXBwcy1kaXNjdXNzQGlldGYub3JnPjsgPHNpcEBpZXRmLm9yZz4NClN1YmplY3Q6IFByb3Bvc2Fs IG9mIE5vbi1TZXF1ZW50aWFsIEdyb3VwIE5vdGlvbiBpbiBBQk5GIHcvIGEgU0lQIGNhc2UNCg0K DQpIaSBhbGwsDQoNCkkgYW0gTXVuam8gWXUgYW5kIGN1cnJlbnRseSB3b3JraW5nIHdpdGggSm9u ZyBTdW5nIEtpbSBvZiBhIG5ldHdvcmsNCnNvbHV0aW9uIHN0YXJ0LXVwIGluIEtvcmVhLCBWaW5l R2VuIEluYy4NCkR1cmluZyB0aGUgNzR0aCBJRVRGIGluIFNhbiBGcmFuY2lzY28sIERhdmUgQ3Jv Y2tlciBhbmQgTGlzYSBEdXNzZWF1bHQNCnN1Z2dlc3RlZCB1cyB0byBwb3N0IGluIHRoZSBBcHBs aWNhdGlvbiBtYWlsaW5nIGxpc3QuDQpBbmQgSSB0aG91Z2h0IHRoZSBTSVAgbWFpbGluZyBsaXN0 IGlzIGEgZ29vZCBwbGFjZSB0b28sIHNpbmNlIHdlIGhhdmUNCmEgdXNlIGNhc2Ugb2Ygb3VyIGV4 dGVuc2lvbiB3aXRoIFNJUC4NCg0KSm9uZyBTdW5nIEtpbSBub3RpY2VkIHRoZXJlIHNob3VsZCBi ZSBhIGJldHRlciB2ZXJzaW9uIG9mIHRoZSBBQk5GDQpkZWZpbml0aW9uIHNlY3Rpb24gb2YgUkZD IDMyNjENCndoaWxlIGRldmVsb3BpbmcgYSAiY29tcGxldGUiIEFCTkYgcGFyc2VyIGdlbmVyYXRv ci4NClRoZSBwYXJzZXIgZ2VuZXJhdG9yIGlzIGNvbXBsZXRlIGluIHRoZSBzZW5zZSB0aGF0IGdl bmVyYXRlZCBwYXJzZXIgY29kZQ0KZG9lcyBub3QgbmVlZCBhbnkgaGFuZCBjb2RpbmcuDQoNCklu IFNlY3Rpb24gNyBvZiBSRkMgMzI2MSwgUmVxdWVzdCBpcyBkZWZpbmVkIGxpa2UgZm9sbG93aW5n Lg0KDQogICBSZXF1ZXN0ICAgICAgICA9ICBSZXF1ZXN0LUxpbmUNCiAgICAgICAgICAgICAgICAg ICAgICooIG1lc3NhZ2UtaGVhZGVyICkNCiAgICAgICAgICAgICAgICAgICAgIENSTEYNCiAgICAg ICAgICAgICAgICAgICAgIFsgbWVzc2FnZS1ib2R5IF0NCg0Kd2hlcmUsDQoNCiAgIG1lc3NhZ2Ut aGVhZGVyICA9ICAoQWNjZXB0DQogICAgICAgICAgICAgICAgICAgLyAgQWNjZXB0LUVuY29kaW5n DQogICAgICAgICAgICAgICAgICAgLg0KICAgICAgICAgICAgICAgICAgIC8gIENhbGwtSUQNCiAg ICAgICAgICAgICAgICAgICAuDQogICAgICAgICAgICAgICAgICAgLyAgQ1NlcQ0KICAgICAgICAg ICAgICAgICAgIC4NCiAgICAgICAgICAgICAgICAgIC8gIFZpYQ0KICAgICAgICAgICAgICAgICAg IC4NCiAgICAgICAgICAgICAgICAgIC8gIGV4dGVuc2lvbi1oZWFkZXIpIENSTEYNCg0KSSBvbWl0 dGVkIG1vc3QgcGFydCBvZiB0aGUgbG9uZyAibWVzc2FnZS1oZWFkZXIiIGZvciBzYWtlIG9mIHJl YWRhYmlsaXR5Lg0KDQpGcm9tIHRoZSBhYm92ZSwgb25lIGNhbiB0ZWxsIHRoYXQgKihtZXNzYWdl LWhlYWRlcikgYWNoaWV2ZXMgYSBncm91cA0Kd2hvc2UgZWxlbWVudHMgYXJlDQpub24tc2VxdWVu dGlhbCBhbmQgb3B0aW9uYWwuDQpTbywgYW55IG9mIHRoZSBmb2xsb3dpbmcgY29tcGxpZXMgd2l0 aCB0aGUgZGVmaW5pdGlvbi4NCg0KKCkgOyBlbXB0eSBncm91cA0KKEFjY2VwdCkNCihBY2NlcHQs IEFjY2VwdCkNCihBY2NlcHQsIENhbGwtSUQpDQooQ2FsbC1JRCwgQWNjZXB0KQ0KDQphbmQgc28g b24uDQoNCkhvd2V2ZXIsIG9ubHkgYSBzbWFsbCBwb3J0aW9uIG9mIGFsbCB0aGUgcG9zc2libGUg Y29tYmluYXRpb25zDQphcmUgbGVnaXRpbWF0ZSBhY2NvcmRpbmcgdG8gc29tZSBzZWN0aW9ucyBs aWtlIDguMS4xIGFzIGZvbGxvd3MuDQoNCiAgIDguMS4xIEdlbmVyYXRpbmcgdGhlIFJlcXVlc3QN Cg0KICAgICAgQSB2YWxpZCBTSVAgcmVxdWVzdCBmb3JtdWxhdGVkIGJ5IGEgVUFDIE1VU1QsIGF0 IGEgbWluaW11bSwgY29udGFpbg0KICAgICAgdGhlIGZvbGxvd2luZyBoZWFkZXIgZmllbGRzOiBU bywgRnJvbSwgQ1NlcSwgQ2FsbC1JRCwgTWF4LUZvcndhcmRzLA0KICAgICAgYW5kIFZpYTsgYWxs IG9mIHRoZXNlIGhlYWRlciBmaWVsZHMgYXJlIG1hbmRhdG9yeSBpbiBhbGwgU0lQDQogICAgICBy ZXF1ZXN0cy4gIFRoZXNlIHNpeCBoZWFkZXIgZmllbGRzIGFyZSB0aGUgZnVuZGFtZW50YWwgYnVp bGRpbmcNCiAgICAgIGJsb2NrcyBvZiBhIFNJUCBtZXNzYWdlLA0KICAgICAgLg0KICAgICAgLg0K DQpBcyBzaG93biBhYm92ZSwgZmV3IGVsZW1lbnRzIGxpa2UgVG8sIEZyb20sIENTZXEsIGFyZSBt YW5kYXRvcnkgLSB0aGUNCmZpcnN0IHNpZ24gdGhhdCB0aGUgQUJORiBkZWZpbml0aW9uIGlzIG5v dCBzZWxmLWNvbnRhaW5lZC4NCkluIGZhY3QsIGFsbCB0aGUgImFkZGl0aW9uYWwiIGRlZmluaXRp b25zIG9mIG1lc3NhZ2UtaGVhZGVyIGFyZQ0KZW1iZWRkZWQgaW4gdmFyaW91cyBzZWN0aW9ucyBp biB0aGUgUkZDDQosIHdoaWNoIG1ha2VzIGl0IGltcHJhY3RpY2FsICggaWYgbm90IGltcG9zc2li bGUgKSB0byBidWlsZCBhIGNvbXBsZXRlDQpwYXJzZXIgZ2VuZXJhdG9yLg0KDQpTbywgSm9uZyBT dW5nIEtpbSBoYWQgdG8gYWRkIGFuIGV4dGVuc2lvbiwgIm5vbi1zZXF1ZW50aWFsIiBncm91cCB0 byBBQk5GLCBhbmQNCmhlIG5hbWVkIGl0IGFzIFNFVCB3aG9zZSBpcyBhbHJlYWR5IGF2YWlsYWJs ZSBlbHNld2hlcmUgbGlrZSBBU04uMQ0KDQpTRVQgaXMgZGVzY3JpYmVkIHNpbXBseSBhcyBmb2xs b3dzLCB1c2luZyBhIHBhaXIgb2YgYnJhY2VzOg0KDQpTRVQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHtSdWxlMSBSdWxlMn0NCg0KVXNpbmcgU0VULCBhIHJlZGVmaW5pdGlvbiBvZiB0aGUg YWJvdmUgUmVxdWVzdCBpcyBzb21ldGhpbmcgbGlrZSBmb2xsb3dpbmc6DQoNCiAgIFJlcXVlc3Qg ICAgICAgID0gIFJlcXVlc3QtTGluZQ0KICAgICAgICAgICAgICAgICAgICAgbWVzc2FnZS1oZWFk ZXINCiAgICAgICAgICAgICAgICAgICAgIENSTEYNCiAgICAgICAgICAgICAgICAgICAgIFsgbWVz c2FnZS1ib2R5IF0NCg0Kd2hlcmUsDQoNCiAgIG1lc3NhZ2UtaGVhZGVyICA9ICB7DQogICAgICAg ICAgICAgICAgICAgQ2FsbC1JRA0KICAgICAgICAgICAgICAgICAgIENTZXENCiAgICAgICAgICAg ICAgICAgICAuDQogICAgICAgICAgICAgICAgICAxKlZpYQ0KICAgICAgICAgICAgICAgICAgIC4N CiAgICAgICAgICAgICAgICAgIDAqMUFjY2VwdA0KICAgICAgICAgICAgICAgICAgMCoxQWNjZXB0 LUVuY29kaW5nDQogICAgICAgICAgICAgICAgICAgLg0KICAgICAgICAgICAgICAgICAgMCoxZXh0 ZW5zaW9uLWhlYWRlcn0gQ1JMRg0KDQpUaGlzIG5ldyB2ZXJzaW9uIG1ha2VzIHF1aXRlIGEgZmV3 IHBhcnRzIG9mIHRoZSBSRkMgcGFyYWdyYXBocw0KdW5uZWNlc3NhcnkgYW5kIHJlZHVuZGFudCwg cmVzdWx0aW5nIGluIGEgc2VsZi1jb250YWluZWQsDQpzdHJhaWdodGZvcndhcmQsIGVhc3ktdG8t bWFpbnRhaW4sIGFuZCBwYXJzZXIgZ2VuZXJhdG9yIGZyaWVuZGx5DQpkZWZpbml0aW9uLg0KDQpX ZSdkIGxpa2UgdG8ga25vdyB3aGF0IFNJUCBmb2xrcyB3b3VsZCB0aGluayBhYm91dCB0aGlzLA0K YW5kIGlmIHRoZXJlIGFyZSBvdGhlciBjYXNlcyB0aGF0IGNhbiBiZW5lZml0IGZyb20gdGhpcyBl eHRlbnNpb24uDQpBbHNvIHdvdWxkIGxpa2UgdG8gaGVhciBmcm9tIEFwcCBmb2xrcywgc3VjaCBh cw0KYmFsYW5jZSBiZXR3ZWVuIGZlYXR1cmUgYW5kIHNpbXBsaWNpdHksIGFyY2hpdGVjdHVyYWwg cG9pbnQsIGV0Yy4NCg0KUmVnYXJkcywNCi1NdW5qbyBZdQ0KDQpQLlMuIHdlJ2QgbGlrZSB0byBl eHByZXNzIG91ciB0aGFua3MgdG8gRGF2ZSBDcm9ja2VyIGFuZCBMaXNhIER1c3NlYXVsdCwNCmFu ZCBvdGhlciBXRyBjaGFpcnMgZm9yIHRoZWlyIGhlbHAgYW5kIGtpbmRuZXNzIGR1cmluZyB0aGUg bWVldGluZy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpBcHBzLURpc2N1c3MgbWFpbGluZyBsaXN0DQpBcHBzLURpc2N1c3NAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo= From dean.willis@softarmor.com Wed Apr 1 22:46:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8796F3A6C1A for ; Wed, 1 Apr 2009 22:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 lv5YIQwHlJmB for ; Wed, 1 Apr 2009 22:46:07 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CC1703A6841 for ; Wed, 1 Apr 2009 22:46:07 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n325kjrm030637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2009 00:46:46 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <49D3B493.4050101@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 00:46:39 -0500 References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , Dan Wing Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 05:46:08 -0000 On Apr 1, 2009, at 1:38 PM, Paul Kyzivat wrote: > > > Dan Wing wrote: >> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] > >>> But the transit ISP should be routing the packets using their >>> source and destination IP addresses, not mucking about in the >>> application protocol. >> The transit SIP provider has every interest in hiding the IP >> addresses >> of their own equipment and of the actual peers. Otherwise, the peers >> may make their own business agreement and circumvent the 'service' >> being provided by the transit SIP provider -- or so the argument >> goes. > > If the peers can circumvent the SP and make their own business > agreement, then perhaps the SP wasn't actually providing a service. > And they're afraid the other folks will find out? Hang 'em from the yardarm, Captain Bligh. Those fellows are pirates! -- Dean From dean.willis@softarmor.com Wed Apr 1 22:47:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335F23A6971 for ; Wed, 1 Apr 2009 22:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 gZifDaF7ADiK for ; Wed, 1 Apr 2009 22:47:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5F2F53A6BD7 for ; Wed, 1 Apr 2009 22:47:27 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n325mN12030662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2009 00:48:24 -0500 Message-Id: <615F2407-ED59-4122-888E-285FC219DA8C@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 00:48:17 -0500 References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> X-Mailer: Apple Mail (2.930.3) Cc: 'Cullen Jennings' , "sip@ietf.org" , 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , Dan Wing Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 05:47:28 -0000 On Apr 1, 2009, at 1:38 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf >> Of Dean >> Willis >> Sent: Wednesday, April 01, 2009 1:47 PM >> >> But the transit ISP should be routing the packets using their source >> and destination IP addresses, not mucking about in the application >> protocol. If some backbone ISP started putting in transparent HTTP >> proxies that diverted Web traffic to alternate sites, we'd have a >> "peasants with torches" scenario. > > That's not analogous and you know it, I think. We're not talking > about a transparent inline IP-layer ISP mucking about in the > application layer. > You're setting the SIP request URI host portion to your local > provider, not the far-end (because you almost never know the far-end > domain, and even if you did they won't accept your request > directly). Your SIP request really does almost always reach the > local provider identified by that URI domain directly first. Being > authoritative for that domain, they then route your request to > another domain, and so on, to reach an entity ultimately identified > by a phone number not a hostname. For another, you know and I know > that web-based communication is not like phone communication. In > many ways SIP is much closer to IM or Email than HTTP, except it > sometimes also costs money. Dude! This is the INTERNET engineering task force. You want private circuit switched networks, see the ITU. -- Dean From dean.willis@softarmor.com Wed Apr 1 22:52:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14BA328C1B1 for ; Wed, 1 Apr 2009 22:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 jCcKOVJJzgRP for ; Wed, 1 Apr 2009 22:52:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 20DC83A6971 for ; Wed, 1 Apr 2009 22:52:03 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n325r0SU030749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2009 00:53:01 -0500 Message-Id: <3610BFF0-662B-4AC1-92A6-FB5579BB415C@softarmor.com> From: Dean Willis To: Dan Wing In-Reply-To: <040b01c9b306$7d1c1d60$c4f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 00:52:55 -0500 References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> <040b01c9b306$7d1c1d60$c4f0200a@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: 'Cullen Jennings' , sip@ietf.org, 'Paul Kyzivat' , "'DRAGE, Keith \(Keith\)'" , 'Francois Audet' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 05:52:04 -0000 On Apr 1, 2009, at 3:14 PM, Dan Wing wrote: > > There continue to be transit IP providers even though the Internet > has been > around for decades, and there continue to be transit PSTN providers > even > though the PSTN has been around for generations. Remember, I'm practicing at challenging "the opposition" to help you clean up your argument, so don't take this the wrong way . . . Transit IP providers don't require changing the core protocols so they can preserve their business models. I'm hesitant to potentially cripple a security mechanism in order to preserve the business model of transit PSTN providers. Seriously: You want the protocol to change, you have to have a reason that makes sense in the context of the Internet. Crazy stuff that people are doing in private networks to justify their financial exchange doesn't qualify as a reason to change accepted Internet architecture. -- Dean From dean.willis@softarmor.com Wed Apr 1 22:56:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE993A6971 for ; Wed, 1 Apr 2009 22:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 L6GnCjLa0Dem for ; Wed, 1 Apr 2009 22:56:50 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6F85C3A6841 for ; Wed, 1 Apr 2009 22:56:50 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n325vf8p030788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2009 00:57:42 -0500 Message-Id: <731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com> From: Dean Willis To: "Dwight, Timothy M (Tim)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 00:57:36 -0500 References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> X-Mailer: Apple Mail (2.930.3) Cc: Cullen Jennings , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 05:56:51 -0000 On Apr 1, 2009, at 4:40 PM, Dwight, Timothy M (Tim) wrote: > Dean, > > Hadriel has answered most of your questions. On this point: > >>> Alternatively, if the SP's infrastructure is in the public address >>> space, you typically don't see NAT / SIP ALG or topology hiding or > media >>> steering. You may (often do) still see "border devices" doing > things >>> like traffic aggregation and policy based routing. >>> >> >> Do we need SDP editing to allow these functions, or is there >> a cleaner way to do it? > > Sorry I wasn't more clear. These functions don't involve SDP editing. > Traffic aggregation (by which I mean to refer to aggregation of SIP > signaling traffic) is usually done with ROUTE headers or use of the > 'maddr' URI parameter, or (most often) through re-targetting in the > border device. Policy routing is some mechanism internal to the > border > device, that it uses to determine how to modify and to where to > forward, > the SIP message. Okay. . . The debate here has been over finding ways to change RFC 474 and/or DTLS/SRTP so that the media key fingerprint is preserved, enabling the full security of DTLS/SRTP. Since RFC 4474 signs "the whole SDP", any edits done to SDP by a middlebox break the RFC 4474 signature, thereby breaking the media key fingerprint protection of RFC 4474 (and thereby allowing a MITM on the media). If traffic aggregation and policy based routing don't require editing SDP in a proxy, then they don't break RFC 4474, and we don't have a problem. Except we MUST have a problem, because several folks keep saying we do. So Cullen et. al. have been pushing us to nail down exactly what the problem is (and saying RFC 4474 is broken by SBCs is not an answer; it is a symptom). So what seems to be the problem? -- Dean From christer.holmberg@ericsson.com Wed Apr 1 22:58:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D2B3A6C15 for ; Wed, 1 Apr 2009 22:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiYFwNRFwDCO for ; Wed, 1 Apr 2009 22:58:13 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BFB893A6BF1 for ; Wed, 1 Apr 2009 22:58:08 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2317F20CA0; Thu, 2 Apr 2009 07:59:08 +0200 (CEST) X-AuditID: c1b4fb3c-ac794bb0000004b9-6c-49d4542934ff Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C3DA220854; Thu, 2 Apr 2009 07:59:05 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 07:57:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 07:57:56 +0200 Message-ID: In-Reply-To: <3610BFF0-662B-4AC1-92A6-FB5579BB415C@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmzV150elovvKDnQfud2eSj3NqjzgAAF6AQ References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com><038701c9b2f3$b88300c0$c4f0200a@cisco.com><49D3B493.4050101@cisco.com><040b01c9b306$7d1c1d60$c4f0200a@cisco.com> <3610BFF0-662B-4AC1-92A6-FB5579BB415C@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , "Dan Wing" X-OriginalArrivalTime: 02 Apr 2009 05:57:57.0837 (UTC) FILETIME=[F90857D0:01C9B357] X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 05:58:14 -0000 >Seriously: You want the protocol to change, you have to have a reason that makes sense in the context of the Internet.=20 >Crazy stuff that people are doing in private networks to justify their financial exchange doesn't qualify as a reason to=20 >change accepted Internet architecture. You could say that, but then you will end up where we are now: nobody implements it :) Regards, Christer From moore@cs.utk.edu Wed Apr 1 21:55:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028993A69F7; Wed, 1 Apr 2009 21:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwHQ9ShPhGdq; Wed, 1 Apr 2009 21:55:02 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 2A22F3A69B8; Wed, 1 Apr 2009 21:54:46 -0700 (PDT) Received: from lust.indecency.org (70-11-3-140.pools.spcsdns.net [70.11.3.140]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH68639 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 21:55:43 -0700 (PDT) Message-ID: <49D44549.2000101@cs.utk.edu> Date: Thu, 02 Apr 2009 00:55:37 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Munjo Yu References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=E1473978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Apr 2009 03:02:06 -0700 Cc: sip@ietf.org, apps-discuss@ietf.org Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 04:55:04 -0000 If memory serves, we discussed a very similar notation within the DRUMS working group (around 12 years ago), which is where the RFC 822 ABNF was generalized
to its present form.  Obviously we decided not to include it.  I don't recall
why, but I think it had something to with the fact that having the n*m notation mean one thing when applied to an expression outside of a "SET", and something else when used inside a "SET", creates an ambiguity in the notation.  You can resolve the ambiguity by various means, but the trick is to keep the result from being
confusing to humans.

Keith

 
Hi all,

I am Munjo Yu and currently working with Jong Sung Kim of a network
solution start-up in Korea, VineGen Inc.
During the 74th IETF in San Francisco, Dave Crocker and Lisa Dusseault
suggested us to post in the Application mailing list.
And I thought the SIP mailing list is a good place too, since we have
a use case of our extension with SIP.

Jong Sung Kim noticed there should be a better version of the ABNF
definition section of RFC 3261
while developing a "complete" ABNF parser generator.
The parser generator is complete in the sense that generated parser code
does not need any hand coding.

In Section 7 of RFC 3261, Request is defined like following.

   Request        =  Request-Line
                     *( message-header )
                     CRLF
                     [ message-body ]

where,

   message-header  =  (Accept
                   /  Accept-Encoding
                   .
                   /  Call-ID
                   .
                   /  CSeq
                   .
                  /  Via
                   .
                  /  extension-header) CRLF

I omitted most part of the long "message-header" for sake of readability.

>From the above, one can tell that *(message-header) achieves a group
whose elements are
non-sequential and optional.
So, any of the following complies with the definition.

() ; empty group
(Accept)
(Accept, Accept)
(Accept, Call-ID)
(Call-ID, Accept)

and so on.

However, only a small portion of all the possible combinations
are legitimate according to some sections like 8.1.1 as follows.

   8.1.1 Generating the Request

      A valid SIP request formulated by a UAC MUST, at a minimum, contain
      the following header fields: To, From, CSeq, Call-ID, Max-Forwards,
      and Via; all of these header fields are mandatory in all SIP
      requests.  These six header fields are the fundamental building
      blocks of a SIP message,
      .
      .

As shown above, few elements like To, From, CSeq, are mandatory - the
first sign that the ABNF definition is not self-contained.
In fact, all the "additional" definitions of message-header are
embedded in various sections in the RFC
, which makes it impractical ( if not impossible ) to build a complete
parser generator.

So, Jong Sung Kim had to add an extension, "non-sequential" group to ABNF, and
he named it as SET whose is already available elsewhere like ASN.1

SET is described simply as follows, using a pair of braces:

SET                             {Rule1 Rule2}

Using SET, a redefinition of the above Request is something like following:

   Request        =  Request-Line
                     message-header
                     CRLF
                     [ message-body ]

where,

   message-header  =  {
                   Call-ID
                   CSeq
                   .
                  1*Via
                   .
                  0*1Accept
                  0*1Accept-Encoding
                   .
                  0*1extension-header} CRLF

This new version makes quite a few parts of the RFC paragraphs
unnecessary and redundant, resulting in a self-contained,
straightforward, easy-to-maintain, and parser generator friendly
definition.

We'd like to know what SIP folks would think about this,
and if there are other cases that can benefit from this extension.
Also would like to hear from App folks, such as
balance between feature and simplicity, architectural point, etc.

Regards,
-Munjo Yu

P.S. we'd like to express our thanks to Dave Crocker and Lisa Dusseault,
and other WG chairs for their help and kindness during the meeting.
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
From moore@cs.utk.edu Wed Apr 1 21:58:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E09F3A694D; Wed, 1 Apr 2009 21:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xed1fylpLgq4; Wed, 1 Apr 2009 21:58:18 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 788BA3A682F; Wed, 1 Apr 2009 21:58:18 -0700 (PDT) Received: from lust.indecency.org (70-11-3-140.pools.spcsdns.net [70.11.3.140]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMH69097 (AUTH admin@network-heretics.com); Wed, 1 Apr 2009 21:59:14 -0700 (PDT) Message-ID: <49D4461E.2050709@cs.utk.edu> Date: Thu, 02 Apr 2009 00:59:10 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: eburger@standardstrack.com References: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> In-Reply-To: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> X-Enigmail-Version: 0.95.7 OpenPGP: id=E1473978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Apr 2009 03:04:17 -0700 Cc: SIP@ietf.org, apps-discuss@ietf.org Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 04:58:19 -0000 eburger wrote: 
Personally, I don't understand why we didn't just use YACC.
Exercise: write an RFC ?822 parse in yacc.  It can be done, but not easily, as the RFC ?822 grammar is not LALR(1).
 I am really in favor of using a formal language for specifying grammar. As Munjo states, the ABNF is essentially documentation fluff - useless at best and wrong at worst. 

As for this particular suggestion, I am ambivalent as to whether we hack ABNF, adopt YACC, or even adopt ASN.1.
One lesson from the DRUMS effort - rewrite an existing grammar at your peril.  Even if the old specification has errors, writing a new grammar which verifiably recognizes exactly the same language as the old one can be difficult.  And even if you restrict the language that new implementations can emit, you generally have to accept the old language for compatibility's sake.  So you end up with two grammars where one was formerly (almost) good enough.

Keith
From jiri@iptel.org Thu Apr 2 05:00:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19563A694F for ; Thu, 2 Apr 2009 05:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTkiX0eQMnZb for ; Thu, 2 Apr 2009 05:00:54 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id BDA7D3A67FA for ; Thu, 2 Apr 2009 05:00:54 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id BF5A7181125F; Thu, 2 Apr 2009 14:01:53 +0200 (CEST) Message-ID: <49D3EEAA.1080006@iptel.org> Date: Thu, 02 Apr 2009 00:46:02 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dean Willis References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List , "Uzelac, Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:00:55 -0000 Dean Willis wrote: > > On Mar 30, 2009, at 8:03 PM, Jiri Kuthan wrote: >> >> There is a timing aspect in favor of placing identity in signaling -- >> I would like to know whose call is ringing before I answer (if I do). > > So, we need identity in signaling, we need identity in media, and we > need the two identity expressions to match. I'm personally happy with having it only in signaling. Should there be some in media too, I would be in favor of keeping those two separate -- I'm not a particular fan of protocol dependencies. That's just not about aesthetic expression -- once a protocol begins to depend on other protocol, which one possibly does not need, the cost and adaptability decreases. Single-purpose things without dependencies have a much sounder chance of deployment. -jiri > > That's what we get with RFC 4474 and DTLS/SRTP. > > Why were we trying to change it to protect something else? > > -- > Dean > From jiri@iptel.org Thu Apr 2 05:00:56 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6493A67FA for ; Thu, 2 Apr 2009 05:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QQhdGX3B0cJ for ; Thu, 2 Apr 2009 05:00:56 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 9F9093A6813 for ; Thu, 2 Apr 2009 05:00:55 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id A31811810C4D; Thu, 2 Apr 2009 14:01:55 +0200 (CEST) Message-ID: <49D400F8.4050304@iptel.org> Date: Thu, 02 Apr 2009 02:04:08 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Cullen Jennings References: <49CE8255.4000103@iptel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:00:56 -0000 Cullen Jennings wrote: > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: > >> >> I'm worried this is only a wishful thinking. While perfectly >> logical, still even in such constrained setups some bizzar >> ALGs do in my experience appear in the middle, change SDP >> and make thus the identity worthless. > > The thing I keep asking is can we make a list of reason why SDP and > headers get changes and in what scenarios they do this. I think it will > be hard to sort how to fix this without being clear what needs to be fixed. A short and probably useless answer is NAT traversal, transcoding and security (possibly illusive) in the scenarios I know. The real trouble is that all sorts of SDP rewriting in the field are a rule, and not rewriting is an exception. It is just so straight-forward to do for the applications I know. It is widely deployed, and here to stay. Relying on e2e SDP integrity by the way of TURN seems to me an alibi at best, if not a hopeless try to reverse history. Therefore I would choose the opposite way and try to learn what are the pieces for which we have a compelling need for integrity. (either way it may be hard to set a demarcation line though). > > For example, one of the things we might want to say is something like: > the Phone is behind a NAT and connects to it's proxy / registrar for > its' domain. That proxy/b2bua whatever mucks with IP/ports in the SDP > for NAT traversal. Then we could ask if 4474 is broken in this case or > not and what might be a good way of solving the problem of having UAs > behind NATs. That's the approach we have taken to deal with media relays for sake of NAT traversal and turned out hard to deploy. I haver considered this good enough for the particular rather simple scenarios I have been interested in. SER calculates the message integrity protection for outbound SDP. Even in such scenarios do ddly ALGs still appear between signer and verifier, and are difficult to get out (even though they are evil and shall not be there in the first place, and are typically controllable by the same company that controls the SIP server). I'm therefore seeking protocols that do not require full SDP integrity along any SIP path segment. Only this way I think we can achieve robustness against ALGs, SBCs, evil boxes, grand applications and what have you, and not limit ourselves to a subset of scnarios understood today. -jiri > > Cullen > From jiri@iptel.org Thu Apr 2 05:00:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470593A6BAE for ; Thu, 2 Apr 2009 05:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFfrOq-2qHbm for ; Thu, 2 Apr 2009 05:00:58 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id E656D3A69EA for ; Thu, 2 Apr 2009 05:00:57 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id B19951810BEE; Thu, 2 Apr 2009 14:01:58 +0200 (CEST) Message-ID: <49D40663.109@iptel.org> Date: Thu, 02 Apr 2009 02:27:15 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Cullen Jennings References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> In-Reply-To: <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:00:59 -0000 Cullen Jennings wrote: > > In all of section 8, the only reason I find of why things are changed is > > "For media steering purposes, B2BUAs in intermediate domains need to > modify the IP address c-lines and the port in m-lines." Hi Cullen, really the trouble is that any list of SDP-mangling scenarios is too short to capture it. as an example, I think ALGs are "illegitimate" in that they do provide only an illusion of security and break things at the same time. Still they do appear withouth what I would call a "good reason" and break things. Therefore I would prefer actually something more end-2-end-ish, in that it is robust in the ends and makes minimum assumptions about network being nice. That's not an argument for encouraging evil things in the network. That's just an argument for being able to deal with them. Does this appear silly? I'm somehow worried I haven't made my point quite well. > Even this one line leaves me confused about what intermediate domains > are in the deployment cases where this happens and if we are talking > about email style address or e.164 style addresses. What an example is > of a deployment where things like this happen and why the middle (not > the end domains) do the media steering. When I ask this of example > people give me, if often turns out what is really wanted is not media > steering but the middle to be able to hide the fact that they actually > delivered the call to a third provider for PSTN termination. My viewpoint is that the case you mention is another element on a list of scenarios, which we may or may not understand, may or may not be reasonable, but very likely will appear in the field and break SDP's integrity. For my own purposes I would be happy if IP+port+codec were not protected but I guess that others would fail elsewhere. > > Pretend 4474 does not even exist for a minute. I don't think it is > unrealizable of me to ask what the problem is we are trying to solve. I wish the callee to know caller's identity. (May or may not be what others are interested in.) The notion of identity is a bit vague -- I'm not refering DNA sort of identity. For mostof the purposes I know a good-enough notion identity accomodates traceability and change-of-change. Traceability gives me the ability to call back and fingerpoint ath the caller. Cost-of-change is prohibitive for those who want to make identity worthless by changing it oon a grand scale. Having DNS in URI IMO accomodates the cost-of-change requirement, as long as we have certainity caller cannot easily use someone else's DNS. A non-sip example to me is car license plates. > Saying 4474 is does not solve the problem may or may not be true but we > are unlikely to have a good conversation about about what we should do > until we understand what we are trying to accomplish. I think it does solve my identity problem, but breaks because of the SDP thing. -jiri > > > On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote: > >> Cullen wrote: >> >> > The thing I keep asking is can we make a list of reason why >> > SDP and headers get changes and in what scenarios they do >> > this. I think it will be hard to sort how to fix this without >> > being clear what needs to be fixed. >> > >> >> Isn't that the function of the text that was placed in section 8 of >> >> http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 >> >> If it is not, then what do you think is missing. >> >> regards >> >> Keith >> >> > -----Original Message----- >> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> > Behalf Of Cullen Jennings >> > Sent: Tuesday, March 31, 2009 11:32 PM >> > To: Jiri Kuthan >> > Cc: sip@ietf.org; Francois Audet >> > Subject: Re: [Sip] francois' comments and why RFC4474 not >> > used in the field >> > >> > >> > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: >> > >> > > >> > > I'm worried this is only a wishful thinking. While >> > perfectly logical, >> > > still even in such constrained setups some bizzar ALGs do in my >> > > experience appear in the middle, change SDP and make thus >> > the identity >> > > worthless. >> > >> > The thing I keep asking is can we make a list of reason why >> > SDP and headers get changes and in what scenarios they do >> > this. I think it will be hard to sort how to fix this without >> > being clear what needs to be fixed. >> > >> > For example, one of the things we might want to say is >> > something like: >> > the Phone is behind a NAT and connects to it's proxy / >> > registrar for its' domain. That proxy/b2bua whatever mucks >> > with IP/ports in the SDP for NAT traversal. Then we could ask >> > if 4474 is broken in this case or not and what might be a >> > good way of solving the problem of having UAs behind NATs. >> > >> > Cullen >> > >> > _______________________________________________ >> > Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol Use >> > sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> > > From jiri@iptel.org Thu Apr 2 05:01:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248663A6CED for ; Thu, 2 Apr 2009 05:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkukpH8hjNwV for ; Thu, 2 Apr 2009 05:00:59 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id B4B8B3A6BA9 for ; Thu, 2 Apr 2009 05:00:58 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 610861810C18; Thu, 2 Apr 2009 14:01:59 +0200 (CEST) Message-ID: <49D406B0.7060205@iptel.org> Date: Thu, 02 Apr 2009 02:28:32 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Cullen Jennings References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> In-Reply-To: <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:01:00 -0000 Cullen Jennings wrote: > > In all of section 8, the only reason I find of why things are changed is > > "For media steering purposes, B2BUAs in intermediate domains need to > modify the IP address c-lines and the port in m-lines." Hi Cullen, really the trouble is that any list of SDP-mangling scenarios is too short to capture it. as an example, I think ALGs are "illegitimate" in that they do provide only an illusion of security and break things at the same time. Still they do appear withouth what I would call a "good reason" and break things. Therefore I would prefer actually something more end-2-end-ish, in that it is robust in the ends and makes minimum assumptions about network being nice. That's not an argument for encouraging evil things in the network. That's just an argument for being able to deal with them. Does this appear silly? I'm somehow worried I haven't made my point quite well. > Even this one line leaves me confused about what intermediate domains > are in the deployment cases where this happens and if we are talking > about email style address or e.164 style addresses. What an example is > of a deployment where things like this happen and why the middle (not > the end domains) do the media steering. When I ask this of example > people give me, if often turns out what is really wanted is not media > steering but the middle to be able to hide the fact that they actually > delivered the call to a third provider for PSTN termination. My viewpoint is that the case you mention is another element on a list of scenarios, which we may or may not understand, may or may not be reasonable, but very likely will appear in the field and break SDP's integrity. For my own purposes I would be happy if IP+port+codec were not protected but I guess that others would fail elsewhere. > > Pretend 4474 does not even exist for a minute. I don't think it is > unrealizable of me to ask what the problem is we are trying to solve. I wish the callee to know caller's identity. (May or may not be what others are interested in.) The notion of identity is a bit vague -- I'm not refering DNA sort of identity. For mostof the purposes I know a good-enough notion identity accomodates traceability and change-of-change. Traceability gives me the ability to call back and fingerpoint ath the caller. Cost-of-change is prohibitive for those who want to make identity worthless by changing it oon a grand scale. Having DNS in URI IMO accomodates the cost-of-change requirement, as long as we have certainity caller cannot easily use someone else's DNS. A non-sip example to me is car license plates. > Saying 4474 is does not solve the problem may or may not be true but we > are unlikely to have a good conversation about about what we should do > until we understand what we are trying to accomplish. I think it does solve my identity problem, but breaks because of the SDP thing. -jiri > > > On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote: > >> Cullen wrote: >> >> > The thing I keep asking is can we make a list of reason why >> > SDP and headers get changes and in what scenarios they do >> > this. I think it will be hard to sort how to fix this without >> > being clear what needs to be fixed. >> > >> >> Isn't that the function of the text that was placed in section 8 of >> >> http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 >> >> If it is not, then what do you think is missing. >> >> regards >> >> Keith >> >> > -----Original Message----- >> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> > Behalf Of Cullen Jennings >> > Sent: Tuesday, March 31, 2009 11:32 PM >> > To: Jiri Kuthan >> > Cc: sip@ietf.org; Francois Audet >> > Subject: Re: [Sip] francois' comments and why RFC4474 not >> > used in the field >> > >> > >> > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: >> > >> > > >> > > I'm worried this is only a wishful thinking. While >> > perfectly logical, >> > > still even in such constrained setups some bizzar ALGs do in my >> > > experience appear in the middle, change SDP and make thus >> > the identity >> > > worthless. >> > >> > The thing I keep asking is can we make a list of reason why >> > SDP and headers get changes and in what scenarios they do >> > this. I think it will be hard to sort how to fix this without >> > being clear what needs to be fixed. >> > >> > For example, one of the things we might want to say is >> > something like: >> > the Phone is behind a NAT and connects to it's proxy / >> > registrar for its' domain. That proxy/b2bua whatever mucks >> > with IP/ports in the SDP for NAT traversal. Then we could ask >> > if 4474 is broken in this case or not and what might be a >> > good way of solving the problem of having UAs behind NATs. >> > >> > Cullen >> > >> > _______________________________________________ >> > Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol Use >> > sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> > > From christer.holmberg@ericsson.com Thu Apr 2 05:03:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F273A6CFC for ; Thu, 2 Apr 2009 05:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YtBRWeybI4G for ; Thu, 2 Apr 2009 05:03:48 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 175863A699A for ; Thu, 2 Apr 2009 05:03:29 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0932022256 for ; Thu, 2 Apr 2009 14:02:48 +0200 (CEST) X-AuditID: c1b4fb3e-abfb5bb000006d6d-b5-49d4a9674ba6 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B3317221BF for ; Thu, 2 Apr 2009 14:02:47 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 14:02:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B38A.D72DC1B9" Date: Thu, 2 Apr 2009 14:02:05 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acmym8OanYrcZUyMQeinTO+WHiaadQA7riNQ References: From: "Christer Holmberg" To: X-OriginalArrivalTime: 02 Apr 2009 12:02:15.0096 (UTC) FILETIME=[DCF96380:01C9B38A] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:03:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B38A.D72DC1B9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Please also note that the WGLC process har started for the draft. =20 I know that a number of people have read the draft, and the -07 version should cover all the comments and open issues, but it is still good to make sure all editorials etc are in order :) =20 Thanks! =20 Christer ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, April 01, 2009 8:31 AM To: sip@ietf.org Subject: [Sip] Draft new version: draft-ietf-sip-199-07 Hi,=20 I have put together a new version (-07) of the 199 draft, based on the latest discussions.=20 The changes are in chapters 5 (new note added) and 6 (text simplified). 100rel and SDP o/a impacts have also been added to chapters 5 and 6 (I have still kept chapters 9 and 10, though). http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt =20 Regards,=20 Christer=20 ------_=_NextPart_001_01C9B38A.D72DC1B9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: draft-ietf-sip-199-07
Hi,
 
Please also note that the WGLC process har = started for=20 the draft.
 
I know that a number of people have read the = draft, and=20 the -07 version should cover all the comments and open issues, but it is = still=20 good to make sure all editorials etc are in order :)
 
Thanks!
 
Christer

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Christer=20 Holmberg
Sent: Wednesday, April 01, 2009 8:31 AM
To: = sip@ietf.org
Subject: [Sip] Draft new version:=20 draft-ietf-sip-199-07


Hi,

I have put together a new version (-07) = of the 199=20 draft, based on the latest discussions.

The changes are in chapters 5 (new note = added) and 6=20 (text simplified). 100rel and SDP o/a impacts have also been added to = chapters 5=20 and 6 (I have still kept chapters 9 and 10, though).

http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt=20

Regards,

Christer

------_=_NextPart_001_01C9B38A.D72DC1B9-- From HKaplan@acmepacket.com Thu Apr 2 05:54:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95FC3A69B7 for ; Thu, 2 Apr 2009 05:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh7j0kiox46b for ; Thu, 2 Apr 2009 05:54:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 095543A6947 for ; Thu, 2 Apr 2009 05:54:12 -0700 (PDT) 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.340.0; Thu, 2 Apr 2009 08:55:13 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 2 Apr 2009 08:55:13 -0400 From: Hadriel Kaplan To: Dean Willis Date: Thu, 2 Apr 2009 08:55:11 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmzVrF+JGgazknqRFuKqnFCexln+AAOh+Dw Message-ID: References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <615F2407-ED59-4122-888E-285FC219DA8C@softarmor.com> In-Reply-To: <615F2407-ED59-4122-888E-285FC219DA8C@softarmor.com> 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 Cc: 'Cullen Jennings' , "sip@ietf.org" , 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , Dan Wing Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:54:14 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, April 02, 2009 1:48 AM >=20 > Dude! This is the INTERNET engineering task force. You want private > circuit switched networks, see the ITU. That's odd, I could have sworn the IETF defined MPLS-TE, VPLS, PWE3, BGP/MP= LS L3VPNs, tunnel-mode IPsec, SOCKS, and TURN. Has anyone notified the rel= evant WG's to notify them they don't belong in the IETF religious sect? -hadriel From HKaplan@acmepacket.com Thu Apr 2 06:27:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03A353A6A86 for ; Thu, 2 Apr 2009 06:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 v5VXizTjva0x for ; Thu, 2 Apr 2009 06:27:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B8DF33A6A4E for ; Thu, 2 Apr 2009 06:27:09 -0700 (PDT) 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.340.0; Thu, 2 Apr 2009 09:28:09 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 2 Apr 2009 09:28:09 -0400 From: Hadriel Kaplan To: Dean Willis , Paul Kyzivat Date: Thu, 2 Apr 2009 09:28:08 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmzVo0FAz+cjY5TQk+T4ofg9mc8oQAO8fCg Message-ID: References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> In-Reply-To: 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 Cc: 'Cullen Jennings' , "sip@ietf.org" , 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , Dan Wing Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:27:11 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dea= n > Willis > Sent: Thursday, April 02, 2009 1:47 AM > > > If the peers can circumvent the SP and make their own business > > agreement, then perhaps the SP wasn't actually providing a service. > > >=20 > And they're afraid the other folks will find out? Hang 'em from the > yardarm, Captain Bligh. Those fellows are pirates! I don't think they hide them to avoid circumvention - at least not in the g= eneral case. I've heard that argument a few times, but not often. Provide= rs already know who the origination and termination providers are (they're = identified in the NPAC/LERG/etc.), but they just can't reasonably peer dire= ct with everyone. There's a demand/need for transit providers mostly becau= se phone calls cost money, are nationally regulated, users/law-enforcement = expect traceability, and there's a need for identity (ironically). =20 Anytime money is involved, for example, it means you need a business relati= onship to handle billing arrangements, and providers clearly can't scale to= have a business relationship with every other provider/domain/Enterprise o= n the planet. Heck, even in the PSTN right now, SMS messages between very = large mobile providers in the same country go through a middleman, purely b= ecause the middleman acts as the arbiter for billing. I'm not saying some transits don't fear circumvention - IP transits feared = it too when BGP first came out and advertised AS paths - I'm just saying it= 's not the only, or even a primary, reason for SDP changing in transits. T= here are really a lot of reasons the media gets steered through transit pro= viders. The first one is probably: because that's what is being billed/pai= d-for. You yourself, Dean, have said many times that one shouldn't bill on= signaling, but rather bill on media. So providers sort of do that - they = bill on the signaling, but they open/close gates on the media to enforce th= at billing. Then of course they also like to measure the QoS of the media = (and sometimes make call routing decisions based on it even), monitor that = there actually is media and that the call didn't just mysteriously fail, et= c. If phone calls were free for everyone, had no regulation, etc., then I woul= d expect transit providers to not steer media. (I would in fact expect no t= ransit providers period, ultimately) If there's no value in something, the= n there's nothing to protect/monitor/troubleshoot/hide/arbitrate/provide-se= rvice-for.=20 -hadriel p.s. and not all transits do change SDP, and some only change SDP in certai= n circumstances (like for transcoding). From timothy.dwight@verizon.com Thu Apr 2 07:01:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FB23A69DC for ; Thu, 2 Apr 2009 07:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 UYsso5p+YXLs for ; Thu, 2 Apr 2009 07:01:15 -0700 (PDT) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id 245A93A69D0 for ; Thu, 2 Apr 2009 07:01:15 -0700 (PDT) Received: from omzismtp02.vzbi.com ([165.122.46.167]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHH0005389B5T00@firewall.verizonbusiness.com> for sip@ietf.org; Thu, 02 Apr 2009 14:00:48 +0000 (GMT) Received: from omzismtp02.vzbi.com ([127.0.0.1]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHH00I8K89BM200@omzismtp02.vzbi.com> for sip@ietf.org; Thu, 02 Apr 2009 14:00:47 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([153.39.68.168]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KHH00IEL89ADF00@omzismtp02.vzbi.com> for sip@ietf.org; Thu, 02 Apr 2009 14:00:47 +0000 (GMT) Received: from ASHEVS015.vzbi.com ([153.39.71.98]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 02 Apr 2009 14:00:47 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Date: Thu, 02 Apr 2009 13:59:46 +0000 Message-id: In-reply-to: <731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-index: AcmzV/t8DyOXj1VeS4KewyiMwDkRSgAPe3WQ References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> <731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com> From: "Dwight, Timothy M (Tim)" To: Dean Willis X-OriginalArrivalTime: 02 Apr 2009 14:00:47.0194 (UTC) FILETIME=[6C1D6BA0:01C9B39B] Cc: Cullen Jennings , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 14:01:16 -0000 Dean,=20 > On Apr 1, 2009, at 4:40 PM, Dwight, Timothy M (Tim) wrote: >=20 > > Dean, > > > > Hadriel has answered most of your questions. On this point: > > > >>> Alternatively, if the SP's infrastructure is in the public address > >>> space, you typically don't see NAT / SIP ALG or topology hiding or media > >>> steering. You may (often do) still see "border devices" doing things > >>> like traffic aggregation and policy based routing. > >>> > >> > >> Do we need SDP editing to allow these functions, or is there > >> a cleaner way to do it? > > > > Sorry I wasn't more clear. These functions don't involve SDP editing. > > Traffic aggregation (by which I mean to refer to aggregation of SIP > > signaling traffic) is usually done with ROUTE headers or use of the > > 'maddr' URI parameter, or (most often) through re-targetting in the > > border device. Policy routing is some mechanism internal to the =20 > > border > > device, that it uses to determine how to modify and to where to =20 > > forward, > > the SIP message. >=20 > Okay. . . >=20 > The debate here has been over finding ways to change RFC 474 and/or =20 > DTLS/SRTP so that the media key fingerprint is preserved,=20 > enabling the =20 > full security of DTLS/SRTP. Since RFC 4474 signs "the whole=20 > SDP", any =20 > edits done to SDP by a middlebox break the RFC 4474=20 > signature, thereby =20 > breaking the media key fingerprint protection of RFC 4474=20 > (and thereby =20 > allowing a MITM on the media). If traffic aggregation and=20 > policy based =20 > routing don't require editing SDP in a proxy, then they don't break =20 > RFC 4474, and we don't have a problem. >=20 > Except we MUST have a problem, because several folks keep=20 > saying we do. >=20 > So Cullen et. al. have been pushing us to nail down exactly what the =20 > problem is (and saying RFC 4474 is broken by SBCs is not an=20 > answer; it =20 > is a symptom). >=20 > So what seems to be the problem? I think first of all that we're suffering from a long email thread that has been snipped a few times, hence we've lost some of the context. Previously I said there are 2 basic ways that VoIP interconnections are designed: 1) media pinned at each network border 2) media not pinned at the borders The above text refers to case #2. If media is not pinned (by which I mean "steered" to a specific point of network ingress), the things that the border elements do don't seem to break RFC 4474. I am happy to hear that. So the problem seems isolated to interconnect designs involving pinning the media. =20 And the question becomes, why do operators do that? Again speaking only based on my own experience, the rationale is related to the transit service provided to the media. If the media is going to be carried (and in practice prioritized) by the transit operator, that operator will generally want to measure and/or police its arrival rate. Sometimes this is per microflow, other times it is applied to the aggregate; that depends on the SLA. Either way, these (and L3 encapsulation and QoS marking) are functions provided by the device to which the media is "steered" by fiddling with the SDP. I am (in general, operators are) aware that just because a transit operator touches the signaling does not mean it needs to be or should be in the media path. But there are possible designs (e.g., a series of private IP networks) where it may be viewed as desirable. Equally, there are designs (e.g., a group of operators sharing a common IP network) where media pinning is unnecessary (*). Ergo both design approaches exist. It may be tempting to wish this problem away by "outlawing" interconnect designs involving pinning the media; but IMHO that would be wishful thinking. (*) this is a simplified argument. In practice SDP manipulation may be required even in the "multiple operators sharing a common IP network" scenario; e.g., to support Lawful Intercept. Tim From henry@sinnreich.net Thu Apr 2 07:12:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5432C28B56A for ; Thu, 2 Apr 2009 07:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 S9ou8fLtAcx0 for ; Thu, 2 Apr 2009 07:12:25 -0700 (PDT) Received: from outbound-mail-117.bluehost.com (outbound-mail-117.bluehost.com [69.89.22.17]) by core3.amsl.com (Postfix) with SMTP id 1986D3A6ABE for ; Thu, 2 Apr 2009 07:12:24 -0700 (PDT) Received: (qmail 856 invoked by uid 0); 2 Apr 2009 14:13:25 -0000 Received: from unknown (HELO box522.bluehost.com) (74.220.219.122) by outboundproxy3.bluehost.com with SMTP; 2 Apr 2009 14:13:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=sinnreich.net; h=Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version:Content-type:X-Identified-User; b=SIpV91nwSzOobhPLcwrmaVHmUW0JErnw3jR885Hg/nK9xOUZlH7ZLtEW4Tm31v/x9pFtQYW20MBNhJhNQ8DNSRWBP8l2PWVzc7tb0ARmA/zerAKj/eqhLJuskeSCAijN; Received: from cpe-76-186-237-58.tx.res.rr.com ([76.186.237.58] helo=[192.168.0.33]) by box522.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LpNfY-0002f7-Tw; Thu, 02 Apr 2009 08:13:25 -0600 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 02 Apr 2009 07:13:16 -0700 From: "henry@sinnreich.net" To: Hadriel Kaplan , Dean Willis , Paul Kyzivat Message-ID: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmzVo0FAz+cjY5TQk+T4ofg9mc8oQAO8fCgAAK1aok= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3321501204_4919911" X-Identified-User: {35212:box522.bluehost.com:sinnreic:sinnreich.net} {sentby:smtp auth 76.186.237.58 authed with henry@sinnreich.net} X-Mailman-Approved-At: Thu, 02 Apr 2009 08:21:59 -0700 Cc: Cullen Jennings , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" , Dan Wing Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 14:12:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3321501204_4919911 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hadriel, >If phone calls were free for everyone, had no regulation, etc., then I would expect transit providers to not steer media. >(I would in fact expect no transit providers period, ultimately) Fortunately this is already happening as you may know if you have to make international voice calls using your own SIP box, Skype or any other. You can also see this acknowledged in the trade press. >If there's no value in something, then there's nothing to protect/monitor/troubleshoot/hide/arbitrate/provide-service-for. You have said it here in a nutshell IMO. The Google Mlab tools are just the beginning so far to insure there are no devices mucking with packets e2e. http://www.measurementlab.net/measurement-lab-tools The genie is out of the bottle and more tools will likely be made available by other organizations to protect Internet users. Henry On 4/2/09 6:28 AM, "Hadriel Kaplan" wrote: > > > >> > -----Original Message----- >> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean >> > Willis >> > Sent: Thursday, April 02, 2009 1:47 AM >> > >>> > > If the peers can circumvent the SP and make their own business >>> > > agreement, then perhaps the SP wasn't actually providing a service. >>> > > >> > >> > And they're afraid the other folks will find out? Hang 'em from the >> > yardarm, Captain Bligh. Those fellows are pirates! > > I don't think they hide them to avoid circumvention - at least not in the > general case. I've heard that argument a few times, but not often. Providers > already know who the origination and termination providers are (they're > identified in the NPAC/LERG/etc.), but they just can't reasonably peer direct > with everyone. There's a demand/need for transit providers mostly because > phone calls cost money, are nationally regulated, users/law-enforcement expect > traceability, and there's a need for identity (ironically). > > Anytime money is involved, for example, it means you need a business > relationship to handle billing arrangements, and providers clearly can't scale > to have a business relationship with every other provider/domain/Enterprise on > the planet. Heck, even in the PSTN right now, SMS messages between very large > mobile providers in the same country go through a middleman, purely because > the middleman acts as the arbiter for billing. > > I'm not saying some transits don't fear circumvention - IP transits feared it > too when BGP first came out and advertised AS paths - I'm just saying it's not > the only, or even a primary, reason for SDP changing in transits. There are > really a lot of reasons the media gets steered through transit providers. The > first one is probably: because that's what is being billed/paid-for. You > yourself, Dean, have said many times that one shouldn't bill on signaling, but > rather bill on media. So providers sort of do that - they bill on the > signaling, but they open/close gates on the media to enforce that billing. > Then of course they also like to measure the QoS of the media (and sometimes > make call routing decisions based on it even), monitor that there actually is > media and that the call didn't just mysteriously fail, etc. > > If phone calls were free for everyone, had no regulation, etc., then I would > expect transit providers to not steer media. (I would in fact expect no > transit providers period, ultimately) If there's no value in something, then > there's nothing to > protect/monitor/troubleshoot/hide/arbitrate/provide-service-for. > > -hadriel > p.s. and not all transits do change SDP, and some only change SDP in certain > circumstances (like for transcoding). > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --B_3321501204_4919911 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Sip] francois' comments and why RFC4474 not used in the field</= TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:14pt= '>Hadriel,<BR> <BR> >If phone calls were free for everyone, had no regulation, etc., then I = would expect transit providers to not steer media. <BR> >(I would in fact expect no transit providers period, ultimately)  = <BR> <BR> Fortunately this is already happening as you may know if you have to make i= nternational voice calls using your own SIP box, Skype or any other.<BR> You can also see this acknowledged in the trade press.<BR> <BR> >If there's no value in something, then there's nothing to protect/monit= or/troubleshoot/hide/arbitrate/provide-service-for.<BR> You have said it here in a nutshell IMO.<BR> <BR> The Google Mlab tools are just the beginning so far to insure there are no = devices mucking with packets e2e.<BR> <a href=3D"http://www.measurementlab.net/measurement-lab-tools">http://www.me= asurementlab.net/measurement-lab-tools</a><BR> The genie is out of the bottle and more tools will likely be made available= by other organizations to protect Internet users.<BR> <BR> Henry<BR> <BR> <BR> On 4/2/09 6:28 AM, "Hadriel Kaplan" <<a href=3D"HKaplan@acmepack= et.com">HKaplan@acmepacket.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:14pt'><BR> <BR> <BR> > -----Original Message-----<BR> > From: <a href=3D"sip-bounces@ietf.org">sip-bounces@ietf.org</a> [<a href= =3D"mailto:sip-bounces@ietf.org">mailto:sip-bounces@ietf.org</a>] On Behalf Of= Dean<BR> > Willis<BR> > Sent: Thursday, April 02, 2009 1:47 AM<BR> ><BR> > > If the peers can circumvent the SP and make their own business<BR= > > > agreement, then perhaps the SP wasn't actually providing a servic= e.<BR> > ><BR> ><BR> > And they're afraid the other folks will find out? Hang 'em from the<BR= > > yardarm, Captain Bligh. Those fellows are pirates!<BR> <BR> I don't think they hide them to avoid circumvention - at least not in the g= eneral case.  I've heard that argument a few times, but not often. &nbs= p;Providers already know who the origination and termination providers are (= they're identified in the NPAC/LERG/etc.), but they just can't reasonably pe= er direct with everyone.  There's a demand/need for transit providers m= ostly because phone calls cost money, are nationally regulated, users/law-en= forcement expect traceability, and there's a need for identity (ironically).= <BR> <BR> Anytime money is involved, for example, it means you need a business relati= onship to handle billing arrangements, and providers clearly can't scale to = have a business relationship with every other provider/domain/Enterprise on = the planet.  Heck, even in the PSTN right now, SMS messages between ver= y large mobile providers in the same country go through a middleman, purely = because the middleman acts as the arbiter for billing.<BR> <BR> I'm not saying some transits don't fear circumvention - IP transits feared = it too when BGP first came out and advertised AS paths - I'm just saying it'= s not the only, or even a primary, reason for SDP changing in transits. &nbs= p;There are really a lot of reasons the media gets steered through transit p= roviders.  The first one is probably: because that's what is being bill= ed/paid-for.  You yourself, Dean, have said many times that one shouldn= 't bill on signaling, but rather bill on media.  So providers sort of d= o that - they bill on the signaling, but they open/close gates on the media = to enforce that billing.  Then of course they also like to measure the = QoS of the media (and sometimes make call routing decisions based on it even= ), monitor that there actually is media and that the call didn't just myster= iously fail, etc.<BR> <BR> If phone calls were free for everyone, had no regulation, etc., then I woul= d expect transit providers to not steer media. (I would in fact expect no tr= ansit providers period, ultimately)  If there's no value in something, = then there's nothing to protect/monitor/troubleshoot/hide/arbitrate/provide-= service-for.<BR> <BR> -hadriel<BR> p.s. and not all transits do change SDP, and some only change SDP in certai= n circumstances (like for transcoding).<BR> <BR> _______________________________________________<BR> Sip mailing list  <a href=3D"https://www.ietf.org/mailman/listinfo/sip">= https://www.ietf.org/mailman/listinfo/sip</a><BR> This list is for NEW development of the core SIP Protocol<BR> Use <a href=3D"sip-implementors@cs.columbia.edu">sip-implementors@cs.columbia= .edu</a> for questions on current sip<BR> Use <a href=3D"sipping@ietf.org">sipping@ietf.org</a> for new developments on= the application of sip<BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3321501204_4919911-- From henry@sinnreich.net Thu Apr 2 07:34:59 2009 Return-Path: <henry@sinnreich.net> X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB0A28C18E for <sip@core3.amsl.com>; Thu, 2 Apr 2009 07:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.581 X-Spam-Level: X-Spam-Status: No, score=-0.581 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 DpRQd9zPHH+L for <sip@core3.amsl.com>; Thu, 2 Apr 2009 07:34:57 -0700 (PDT) Received: from outbound-mail-23.bluehost.com (outbound-mail-23.bluehost.com [69.89.21.18]) by core3.amsl.com (Postfix) with SMTP id A5ABF28C1FD for <sip@ietf.org>; Thu, 2 Apr 2009 07:34:57 -0700 (PDT) Received: (qmail 20093 invoked by uid 0); 2 Apr 2009 13:35:45 -0000 Received: from unknown (HELO box522.bluehost.com) (74.220.219.122) by outboundproxy2.bluehost.com with SMTP; 2 Apr 2009 13:35:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=sinnreich.net; h=Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version:Content-type:X-Identified-User; b=MVZluhPdzlMO/FRiOD8cw9KtHXL/jAaakkK2CZYyJze5FNMKdcCh5whzzh14w5DbD6AV3nNysTc+QvuFDAvLFNoOrU8vg4fqF9B0SSGAHKidbOblEd4a+qqjCpxTR4lV; Received: from cpe-76-186-237-58.tx.res.rr.com ([76.186.237.58] helo=[192.168.0.33]) by box522.bluehost.com with esmtpa (Exim 4.69) (envelope-from <henry@sinnreich.net>) id 1LpO1N-0000rI-24; Thu, 02 Apr 2009 08:35:57 -0600 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 02 Apr 2009 07:35:50 -0700 From: "henry@sinnreich.net" <henry@sinnreich.net> To: Hadriel Kaplan <HKaplan@acmepacket.com>, Dean Willis <dean.willis@softarmor.com>, Paul Kyzivat <pkyzivat@cisco.com> Message-ID: <C5FA1B56.CDCB%henry@sinnreich.net> Thread-Topic: Mlab Tools Thread-Index: AcmzVo0FAz+cjY5TQk+T4ofg9mc8oQAO8fCgAAN/Lek= In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC315048C4B7E@mail> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3321502557_4980352" X-Identified-User: {35212:box522.bluehost.com:sinnreic:sinnreich.net} {sentby:smtp auth 76.186.237.58 authed with henry@sinnreich.net} X-Mailman-Approved-At: Thu, 02 Apr 2009 08:22:15 -0700 Cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org, Francois Audet <audet@nortel.com>, "DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com>, Dan Wing <dwing@Cisco.COM> Subject: [Sip] Mlab Tools X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol <sip.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sip> List-Post: <mailto:sip@ietf.org> List-Help: <mailto:sip-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2009 14:34:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3321502557_4980352 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sorry for the error of not attributing the MLab Tools to the large International community involved in this initiative. http://www.measurementlab.net/who The fact that most are from academia is a reminder who first built out the global Internet. Even more encouraging is the fact of having so many CS students cherish it and most likely working to defend it. No doubt, enlightened service providers are also comparing their diminishing voice revenue with the growing revenue from Internet access, fixed and mobile. >>If there's no value in something, then there's nothing to protect/monitor/troubleshoot/hide/arbitrate/provide-service-for. Yes, exactly Henry ==================================== Hadriel, >If phone calls were free for everyone, had no regulation, etc., then I would expect transit providers to not steer media. >(I would in fact expect no transit providers period, ultimately) Fortunately this is already happening as you may know if you have to make international voice calls using your own SIP box, Skype or any other. You can also see this acknowledged in the trade press. >If there's no value in something, then there's nothing to protect/monitor/troubleshoot/hide/arbitrate/provide-service-for. You have said it here in a nutshell IMO. The Google Mlab tools are just the beginning so far to insure there are no devices mucking with packets e2e. http://www.measurementlab.net/measurement-lab-tools The genie is out of the bottle and more tools will likely be made available by other organizations to protect Internet users. Henry On 4/2/09 6:28 AM, "Hadriel Kaplan" <HKaplan@acmepacket.com> wrote: > > > >> > -----Original Message----- >> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean >> > Willis >> > Sent: Thursday, April 02, 2009 1:47 AM >> > >>> > > If the peers can circumvent the SP and make their own business >>> > > agreement, then perhaps the SP wasn't actually providing a service. >>> > > >> > >> > And they're afraid the other folks will find out? Hang 'em from the >> > yardarm, Captain Bligh. Those fellows are pirates! > > I don't think they hide them to avoid circumvention - at least not in the > general case. I've heard that argument a few times, but not often. Providers > already know who the origination and termination providers are (they're > identified in the NPAC/LERG/etc.), but they just can't reasonably peer direct > with everyone. There's a demand/need for transit providers mostly because > phone calls cost money, are nationally regulated, users/law-enforcement expect > traceability, and there's a need for identity (ironically). > > Anytime money is involved, for example, it means you need a business > relationship to handle billing arrangements, and providers clearly can't scale > to have a business relationship with every other provider/domain/Enterprise on > the planet. Heck, even in the PSTN right now, SMS messages between very large > mobile providers in the same country go through a middleman, purely because > the middleman acts as the arbiter for billing. > > I'm not saying some transits don't fear circumvention - IP transits feared it > too when BGP first came out and advertised AS paths - I'm just saying it's not > the only, or even a primary, reason for SDP changing in transits. There are > really a lot of reasons the media gets steered through transit providers. The > first one is probably: because that's what is being billed/paid-for. You > yourself, Dean, have said many times that one shouldn't bill on signaling, but > rather bill on media. So providers sort of do that - they bill on the > signaling, but they open/close gates on the media to enforce that billing. > Then of course they also like to measure the QoS of the media (and sometimes > make call routing decisions based on it even), monitor that there actually is > media and that the call didn't just mysteriously fail, etc. > > If phone calls were free for everyone, had no regulation, etc., then I would > expect transit providers to not steer media. (I would in fact expect no > transit providers period, ultimately) If there's no value in something, then > there's nothing to > protect/monitor/troubleshoot/hide/arbitrate/provide-service-for. > > -hadriel > p.s. and not all transits do change SDP, and some only change SDP in certain > circumstances (like for transcoding). > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --B_3321502557_4980352 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Mlab Tools Sorry for the error of not attributing the MLab Tools to the large Interna= tional community involved in this initiative.
http://www.measurementlab.net/w= ho

The fact that most are from academia is a reminder who first built out the = global Internet.
Even more encouraging is the fact of having so many CS students cherish it = and most likely working to defend it.
No doubt, enlightened service providers are also comparing their diminishin= g voice revenue with the growing revenue from Internet access, fixed and mob= ile.

>>If there's no value in something, then there's nothing to protect/m= onitor/troubleshoot/hide/arbitrate/provide-service-for.

Yes, exactly

Henry

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Hadriel,

>If phone calls were free for everyone, had no regulation, etc., then I = would expect transit providers to not steer media.
>(I would in fact expect no transit providers period, ultimately)  =

Fortunately this is already happening as you may know if you have to make i= nternational voice calls using your own SIP box, Skype or any other.
You can also see this acknowledged in the trade press.

>If there's no value in something, then there's nothing to protect/monit= or/troubleshoot/hide/arbitrate/provide-service-for.
You have said it here in a nutshell IMO.

The Google Mlab tools are just the beginning so far to insure there are no = devices mucking with packets e2e.
http://www.me= asurementlab.net/measurement-lab-tools
The genie is out of the bottle and more tools will likely be made available= by other organizations to protect Internet users.

Henry


On 4/2/09 6:28 AM, "Hadriel Kaplan" <HKaplan@acmepacket.com> wrote:

<= SPAN STYLE=3D'font-size:14pt'>


> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of= Dean
> Willis
> Sent: Thursday, April 02, 2009 1:47 AM
>
> > If the peers can circumvent the SP and make their own business > > agreement, then perhaps the SP wasn't actually providing a servic= e.
> >
>
> And they're afraid the other folks will find out? Hang 'em from the > yardarm, Captain Bligh. Those fellows are pirates!

I don't think they hide them to avoid circumvention - at least not in the g= eneral case.  I've heard that argument a few times, but not often. &nbs= p;Providers already know who the origination and termination providers are (= they're identified in the NPAC/LERG/etc.), but they just can't reasonably pe= er direct with everyone.  There's a demand/need for transit providers m= ostly because phone calls cost money, are nationally regulated, users/law-en= forcement expect traceability, and there's a need for identity (ironically).=

Anytime money is involved, for example, it means you need a business relati= onship to handle billing arrangements, and providers clearly can't scale to = have a business relationship with every other provider/domain/Enterprise on = the planet.  Heck, even in the PSTN right now, SMS messages between ver= y large mobile providers in the same country go through a middleman, purely = because the middleman acts as the arbiter for billing.

I'm not saying some transits don't fear circumvention - IP transits feared = it too when BGP first came out and advertised AS paths - I'm just saying it'= s not the only, or even a primary, reason for SDP changing in transits. &nbs= p;There are really a lot of reasons the media gets steered through transit p= roviders.  The first one is probably: because that's what is being bill= ed/paid-for.  You yourself, Dean, have said many times that one shouldn= 't bill on signaling, but rather bill on media.  So providers sort of d= o that - they bill on the signaling, but they open/close gates on the media = to enforce that billing.  Then of course they also like to measure the = QoS of the media (and sometimes make call routing decisions based on it even= ), monitor that there actually is media and that the call didn't just myster= iously fail, etc.

If phone calls were free for everyone, had no regulation, etc., then I woul= d expect transit providers to not steer media. (I would in fact expect no tr= ansit providers period, ultimately)  If there's no value in something, = then there's nothing to protect/monitor/troubleshoot/hide/arbitrate/provide-= service-for.

-hadriel
p.s. and not all transits do change SDP, and some only change SDP in certai= n circumstances (like for transcoding).

_______________________________________________
Sip mailing list  = https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia= .edu for questions on current sip
Use sipping@ietf.org for new developments on= the application of sip

--B_3321502557_4980352-- From AUDET@nortel.com Thu Apr 2 08:38:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EE13A6A29 for ; Thu, 2 Apr 2009 08:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXFFqSg74Eiy for ; Thu, 2 Apr 2009 08:38:09 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0342B3A689E for ; Thu, 2 Apr 2009 08:38:08 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n32FcUi22633; Thu, 2 Apr 2009 15:38:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 10:38:30 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D3B4070@zrc2hxm0.corp.nortel.com> In-Reply-To: <731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmzV/e5szpaDO6eTX29tzXIzcNX7AAUGdSQ References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> <731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Dwight, Timothy M (Tim)" Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 15:38:10 -0000 =20 > Except we MUST have a problem, because several folks keep=20 > saying we do. >=20 > So Cullen et. al. have been pushing us to nail down exactly=20 > what the problem is (and saying RFC 4474 is broken by SBCs is=20 > not an answer; it is a symptom). >=20 > So what seems to be the problem? The problem is that people seem to prefer changing the SDP than using TURN, because it is easier and more convenient. And what draft-wing-sip-identity-media does is show how and 4474-like mechanism that doesn't protect the IP address can be used in conjunction with DTLS-SRTP, to provide an adequate level of security. So, I'll repeat the question from a previous email: what's wrong with=20 draft-wing-sip-identity-media??? From dwing@cisco.com Thu Apr 2 08:52:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9726D3A6DF4 for ; Thu, 2 Apr 2009 08:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.631 X-Spam-Level: X-Spam-Status: No, score=-6.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wB3YIWoRDhc for ; Thu, 2 Apr 2009 08:52:24 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 08F983A6DF5 for ; Thu, 2 Apr 2009 08:52:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,314,1235952000"; d="scan'208";a="150039554" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 02 Apr 2009 15:48:05 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n32Fm56D019015; Thu, 2 Apr 2009 08:48:05 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n32Fm51j003859; Thu, 2 Apr 2009 15:48:05 GMT From: "Dan Wing" To: "'Dean Willis'" References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> <040b01c9b306$7d1c1d60$c4f0200a@cisco.com> <3610BFF0-662B-4AC1-92A6-FB5579BB415C@softarmor.com> Date: Thu, 2 Apr 2009 08:48:05 -0700 Message-ID: <071c01c9b3aa$69a05fe0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <3610BFF0-662B-4AC1-92A6-FB5579BB415C@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmzV0nkDJV87CjmS06EUTLH/4Ns9QATnWdQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1481; t=1238687285; x=1239551285; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=qBFGfk0jAx6YE6ePoNXoVvFZRWf1paw7MghFP8rtYTg=; b=gLBe2zvENTh9iQwPfw6v8t409SwN8IKdwNwhDKOFUb8jk94+sLQgGAbn0A Mdwd1XRN7X0Cd2O2baVkeJd85jNBXJ1qQuEVhkhdO1wKlp1KcXkbAg6WooXZ +kkIub1hdd; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Cullen Jennings' , sip@ietf.org, 'Paul Kyzivat' , "'DRAGE, Keith \(Keith\)'" , 'Francois Audet' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 15:52:25 -0000 > Seriously: You want the protocol to change, you have to have > a reason > that makes sense in the context of the Internet. Crazy stuff that > people are doing in private networks to justify their financial > exchange doesn't qualify as a reason to change accepted Internet > architecture. Here is an Internet architecture with SIP transit service providers. The bubble in the middle is "The Internet", enterprises are on the left and the four service providers are on the right: Enterprise A ---- { -------- } --+ { } \ { } { SP-A } { } / { +----- } --+ { | } { +----- } --+ { } \ { } { transit-A } { } / { +----- } --+ { | } { +----- } --+ { } \ { } { transit-B } { } / { +----- } --+ { | } { +----- } --+ { } \ { } { SP-B } { } / Enterprise B ---- { -------- } --+ And it should be realized that call forwarding turns any SP into a transit provider. -d From john.elwell@siemens-enterprise.com Thu Apr 2 12:05:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3317D28C10D for ; Thu, 2 Apr 2009 12:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 tgpuWc1S7WGG for ; Thu, 2 Apr 2009 12:05:14 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id AE38A3A63D3 for ; Thu, 2 Apr 2009 12:05:13 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHH00KBLMEB27@siemenscomms.co.uk> for sip@ietf.org; Thu, 02 Apr 2009 20:06:11 +0100 (BST) Date: Thu, 02 Apr 2009 20:06:09 +0100 From: "Elwell, John" In-reply-to: <90BEE480-5C62-47F5-B7E1-5EE089798623@cisco.com> To: Cullen Jennings Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001BA69F1@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmy22Yz/GyIyQ61SDOV4GKwevE6HAA2bSPQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <90BEE480-5C62-47F5-B7E1-5EE089798623@cisco.com> Cc: sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:05:15 -0000 Cullen, =20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 01 April 2009 16:06 > To: Elwell, John > Cc: DRAGE, Keith (Keith); sip@ietf.org; Francois Audet > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > On Apr 1, 2009, at 4:33 AM, Elwell, John wrote: >=20 > > I would like service providers to chip in here. Suppose I=20 > use service > > providers to establish a call between two enterprises.=20 > Enterprise A =20 > > uses > > SP A for all external traffic, and enterprise B uses SP B for all > > external traffic. We then have a path: > > > > Enterprise A -> SP A -> SP B -> Enterprise B. > > > > What I would like to know is whether SP A and/or SP B would have =20 > > reason > > to change the SDP (also other aspects of the SIP request, but just =20 > > stick > > to SDP for now). If they need to change it, then what=20 > drives this need > > to change the SDP: NAT traversal, topology hiding, media =20 > > steering, ....? > > > > If SPs think they have no reason to change SDP in such situations, =20 > > then > > this part of the problem is solved. However, I very much=20 > doubt that is > > the case. > > > > John >=20 > I think this is exactly the right sort of question to be asking (and =20 > we all agree they have reasons they are currently changing the SDP, =20 > what we need to get at is why). >=20 > I think we also need to know about situations like > > >=20 >=20 > UA A -> SP A -> SP B -> UA B. > Enterprise A -> SP A -> SP B -> SP C -> Enterprise B. [JRE] Yes. >=20 > And reasons SP B would change it. We also need to understand=20 > for each =20 > use case if it is an E.164 number or email style name. We=20 > need to deal =20 > with the cases where one of both of the ends is the PSTN not an =20 > enterprise. We also need to understand the trust=20 > relationships between =20 > the various entities. By that I mean things like "Enterprise B is =20 > willing to trust SP C (who it pays) will not misroute it calls". Or =20 > that UA A trust SP A not to give A's AOR to someone else. [JRE] Yes, but my contention has already been that I will trust SP A (my local SP) to identify a user in SP A's domain, but not to identify a user in some other domain - for that latter case I would trust that other domain (subject to a valid certificate, of course). I would trust an assertion from Amazon.com, but might not trust an assertion from SP.net that I am talking (perhaps through other SPs) with Amazon.com. I suppose in either case transitive trust is involved. In the one case (by trusting Amazon.com) I am really trusting the CA to assert that it is Amazon.com, whereas in the other case I am trusting my SP to assert that it is Amazon.com. The web way of doing things is to trust a CA rather than to trust an intermediary. >=20 > Then we need to go through use case and figure out which=20 > requirements =20 > derive the modification of key headers or bodies and which use cases =20 > happen in real deployments and which ones are purely hypothetical. =20 > They type of reasons for modification of headers/SDP that have been =20 > raised in past include things like topology hiding, media steering, =20 > nat traversal, and protocol repair. [JRE] Some of this is already discussed in the e2e-identity-important draft. People are adding further information about real deployments on this thread. >=20 > Next we need to work on what the problem is. This includes=20 > things like =20 > "I want to know who's phone I will be talking to if I answer this =20 > ringing call so I can decide if I answer the call" or "I want=20 > to know =20 > who's phone I am talking to at the other end so I can decide what I =20 > might say", or "I want to be able to reject all calls at 2am=20 > that are =20 > not from a phone that is listed in my personal address book".=20 > I'm not =20 > proposing any of these are the right problem statement - I'm just =20 > trying to give examples of they type of statement that if we=20 > agreed on =20 > it would help us make progress. [JRE] I thought a lot of this was covered in e2e-identity-important. Maybe its not said in the right way. >=20 > We have proven over and ever again that without understanding what =20 > problem we are trying to fix, we don't get very far. Saying that the =20 > problem is "4474 does not work", does not help in the=20 > slightest. That =20 > may or may not be true but it is not the problem - it's a statement =20 > about if 4474 as a technology helps solve some unspecified=20 > problem or =20 > not. [JRE]The e2e-identity-important draft does not just say "4474 does not work" but looks at use cases, looks at what they are trying to achieve, and also looks at things that get changed by intermediaries, thereby limiting possible solutions. >=20 > I have been advocating for years now that the discussion=20 > about if 4474 =20 > works for problem X or not is not going to get far without some =20 > agreement on what the various values of X are. [JRE] I know. But I can't seem to find a way of expressing X that works for people. Let's try this. Suppose I receive a call from Amazon.com. I want to know that it is from Amazon.com, because my white list will accept calls from Amazon.com and also, when Amazon.com is displayed, I am prepared to interrupt whatever I am doing to answer a call from Amazon.com. I might give an appropriate greeting and I might be prepared to divulge sensitive information to the caller if I know it is Amazon.com. I might even be interested to know the particular caller from Amazon.com, but not necessarily. If I just see that the call is from my SP, or from some other SP that happens to be in the call path, that means nothing to me. My device can't do effective white list filtering, I can't do effective filtering, I can't answer with an appropriate greeting, I can't know whether it is safe to divulge sensitive information during the call. Furthermore, it is not sufficient just to be told it is from Amazon.com. I require authentication based on a trust anchor, which could a well-known CA, or some other certificate I already have in my store by some out-of-band means. This is the problem I am trying to solve. It is also a problem that RFC 4474 is designed to solve, but depending on the number and behaviour of intermediaries, very often RFC 4474 will not solve it. John From john.elwell@siemens-enterprise.com Thu Apr 2 12:14:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829613A6D16 for ; Thu, 2 Apr 2009 12:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=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 m2S57K6wjzT2 for ; Thu, 2 Apr 2009 12:14:54 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 7A4B53A6C2B for ; Thu, 2 Apr 2009 12:14:53 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHH00M47MUH56@siemenscomms.co.uk> for sip@ietf.org; Thu, 02 Apr 2009 20:15:54 +0100 (BST) Date: Thu, 02 Apr 2009 20:15:51 +0100 From: "Elwell, John" In-reply-to: <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> To: Hans Erik van Elburg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001BA69F5@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C9B3C7.71125095" Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmy1W4A/sEsCALgQMWek/JilmzORAA20qqA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> Cc: Cullen Jennings , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:14:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B3C7.71125095 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hans Erik, =20 Yes, except that SBC1 and SBC6 might not matter if the authentication and verification services are collocated with them. =20 John ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: 01 April 2009 15:23 To: Elwell, John Cc: Cullen Jennings; DRAGE, Keith (Keith); sip@ietf.org; Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field =09 =09 In that scenario you have probably passed 6 SBC's :-) =09 Enterprise A (SBC1) -> (SBC2) SP A (SBC3)->(SBC4) SP B (SBC5)-> (SBC6) Enterprise B. =09 /Hans Erik van Elburg =09 =09 =09 On Wed, Apr 1, 2009 at 12:33 PM, Elwell, John wrote: =09 I would like service providers to chip in here. Suppose I use service providers to establish a call between two enterprises. Enterprise A uses SP A for all external traffic, and enterprise B uses SP B for all external traffic. We then have a path: =09 Enterprise A -> SP A -> SP B -> Enterprise B. =09 What I would like to know is whether SP A and/or SP B would have reason to change the SDP (also other aspects of the SIP request, but just stick to SDP for now). If they need to change it, then what drives this need to change the SDP: NAT traversal, topology hiding, media steering, ....? =09 If SPs think they have no reason to change SDP in such situations, then this part of the problem is solved. However, I very much doubt that is the case. =09 John =09 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Cullen Jennings =09 > Sent: 01 April 2009 02:24 > To: DRAGE, Keith (Keith) > Cc: sip@ietf.org; Francois Audet > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > In all of section 8, the only reason I find of why things are > changed is > > "For media steering purposes, B2BUAs in intermediate domains need to > modify the IP address c-lines and the port in m-lines." > Even this one line leaves me confused about what intermediate > domains > are in the deployment cases where this happens and if we are talking > about email style address or e.164 style addresses. What an > example is > of a deployment where things like this happen and why the > middle (not > the end domains) do the media steering. When I ask this of example > people give me, if often turns out what is really wanted is > not media > steering but the middle to be able to hide the fact that they > actually > delivered the call to a third provider for PSTN termination. > > Pretend 4474 does not even exist for a minute. I don't think it is > unrealizable of me to ask what the problem is we are trying > to solve. > Saying 4474 is does not solve the problem may or may not be true but > we are unlikely to have a good conversation about about what > we should > do until we understand what we are trying to accomplish. > > > On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote: > > > Cullen wrote: > > > > > The thing I keep asking is can we make a list of reason why > > > SDP and headers get changes and in what scenarios they do > > > this. I think it will be hard to sort how to fix this without > > > being clear what needs to be fixed. > > > > > > > Isn't that the function of the text that was placed in section 8 of > > > > > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 > > > > If it is not, then what do you think is missing. > > > > regards > > > > Keith > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of Cullen Jennings > > > Sent: Tuesday, March 31, 2009 11:32 PM > > > To: Jiri Kuthan > > > Cc: sip@ietf.org; Francois Audet > > > Subject: Re: [Sip] francois' comments and why RFC4474 not > > > used in the field > > > > > > > > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: > > > > > > > > > > > I'm worried this is only a wishful thinking. While > > > perfectly logical, > > > > still even in such constrained setups some bizzar ALGs do in my > > > > experience appear in the middle, change SDP and make thus > > > the identity > > > > worthless. > > > > > > The thing I keep asking is can we make a list of reason why > > > SDP and headers get changes and in what scenarios they do > > > this. I think it will be hard to sort how to fix this without > > > being clear what needs to be fixed. > > > > > > For example, one of the things we might want to say is > > > something like: > > > the Phone is behind a NAT and connects to it's proxy / > > > registrar for its' domain. That proxy/b2bua whatever mucks > > > with IP/ports in the SDP for NAT traversal. Then we could ask > > > if 4474 is broken in this case or not and what might be a > > > good way of solving the problem of having UAs behind NATs. > > > > > > Cullen > > > > > > _______________________________________________ > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C9B3C7.71125095 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hans Erik,
 
Yes, except that SBC1 and SBC6 might not matter if the=20 authentication and verification services are collocated with=20 them.
 
John

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: 01 April 2009=20 15:23
To: Elwell, John
Cc: Cullen Jennings; DRAGE, = Keith=20 (Keith); sip@ietf.org; Francois Audet
Subject: Re: [Sip] = francois'=20 comments and why RFC4474 not used in the field

In that scenario you have probably passed 6 SBC's=20 :-)

    Enterprise A (SBC1) -> (SBC2) SP A=20 (SBC3)->(SBC4) SP B (SBC5)-> (SBC6) Enterprise B.

/Hans=20 Erik van Elburg


On Wed, Apr 1, 2009 at 12:33 PM, Elwell, John = <john.elwell@siemens-en= terprise.com>=20 wrote:
I=20 would like service providers to chip in here. Suppose I use=20 service
providers to establish a call between two enterprises. = Enterprise=20 A uses
SP A for all external traffic, and enterprise B uses SP B = for=20 all
external traffic. We then have a path:

    =  =20  Enterprise A -> SP A -> SP B -> Enterprise = B.

What I=20 would like to know is whether SP A and/or SP B would have = reason
to=20 change the SDP (also other aspects of the SIP request, but just = stick
to=20 SDP for now). If they need to change it, then what drives this = need
to=20 change the SDP: NAT traversal, topology hiding, media steering,=20 ....?

If SPs think they have no reason to change SDP in such=20 situations, then
this part of the problem is solved. However, I = very much=20 doubt that is
the case.

John


> -----Original Message-----
> = From: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org] = On
>=20 Behalf Of Cullen Jennings
> Sent: 01 April 2009 02:24
> To: DRAGE, = Keith=20 (Keith)
> Cc: sip@ietf.org; Francois=20 Audet
> Subject: Re: [Sip] francois' comments and why RFC4474=20 not
> used in the field
>
>
> In all of = section 8,=20 the only reason I find of why things are
> changed = is
>
>=20 "For media steering purposes, B2BUAs in intermediate domains need = to
>=20 modify the IP address c-lines and the port in m-lines."
> Even = this=20 one line leaves me confused about what intermediate
> = domains
>=20 are in the deployment cases where this happens and if we are = talking
>=20 about email style address or e.164 style addresses. What an
> = example=20 is
> of a deployment where things like this happen and why = the
>=20 middle (not
> the end domains) do the media steering. When I = ask this=20 of example
> people give me, if often turns out what is really = wanted=20 is
> not media
> steering but the middle to be able to = hide the=20 fact that they
> actually
> delivered the call to a = third=20 provider for PSTN termination.
>
> Pretend 4474 does not = even=20 exist for a minute. I don't think it is
> unrealizable of me = to ask=20 what the problem is we are trying
> to solve.
> Saying = 4474 is=20 does not solve the problem may or may not be true but
> we are = unlikely to have a good conversation about about what
> we=20 should
> do until we understand what we are trying to=20 accomplish.
>
>
> On Mar 31, 2009, at 7:00 PM, = DRAGE,=20 Keith (Keith) wrote:
>
> > Cullen wrote:
> = >
>=20 > > The thing I keep asking is can we make a list of reason=20 why
> > > SDP and headers get changes and in what = scenarios they=20 do
> > > this. I think it will be hard to sort how to = fix this=20 without
> > > being clear what needs to be = fixed.
> >=20 >
> >
> > Isn't that the function of the text = that was=20 placed in section 8 of
> >
> >
> http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-= important-03
>=20 >
> > If it is not, then what do you think is = missing.
>=20 >
> > regards
> >
> > Keith
>=20 >
> > > -----Original Message-----
> > > = From: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org] = On
> >=20 > Behalf Of Cullen Jennings
> > > Sent: Tuesday, = March 31,=20 2009 11:32 PM
> > > To: Jiri Kuthan
> > > = Cc: sip@ietf.org; Francois = Audet
> >=20 > Subject: Re: [Sip] francois' comments and why RFC4474 = not
> >=20 > used in the field
> > >
> > >
> = > >=20 On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote:
> > = >
>=20 > > >
> > > > I'm worried this is only a = wishful=20 thinking. While
> > > perfectly logical,
> > = > >=20 still even in such constrained setups some bizzar ALGs do in = my
> >=20 > > experience appear in the middle, change SDP and make = thus
>=20 > > the identity
> > > > worthless.
> = >=20 >
> > > The thing I keep asking is can we make a list = of=20 reason why
> > > SDP and headers get changes and in what = scenarios they do
> > > this. I think it will be hard to = sort=20 how to fix this without
> > > being clear what needs to = be=20 fixed.
> > >
> > > For example, one of the = things we=20 might want to say is
> > > something like:
> > = > the=20 Phone is behind a NAT and connects to it's proxy /
> > > = registrar for its' domain. That proxy/b2bua whatever mucks
> = > >=20 with IP/ports in the SDP for NAT traversal. Then we could = ask
> >=20 > if 4474 is broken in this case or not and what might be = a
> >=20 > good way of solving the problem of having UAs behind = NATs.
> >=20 >
> > > Cullen <in my individual contributor=20 role>
> > >
> > >=20 _______________________________________________
> > > = Sip=20 mailing list  https://www.ietf.org/mailman/listinfo/sip
> = >=20 > This list is for NEW development of the core SIP Protocol = Use
>=20 > > sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
> > > Use sipping@ietf.org for new = developments on=20 the
> application of sip
> > >
>
>=20 _______________________________________________
> Sip mailing = list=20  https://www.ietf.org/mailman/listinfo/sip
> = This=20 list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
> Use sipping@ietf.org for new = developments on=20 the application of=20 = sip
>
_______________________________________________
Sip=20 mailing list  https://www.ietf.org/mailman/listinfo/sip
This = list is=20 for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of=20 sip

------_=_NextPart_001_01C9B3C7.71125095-- From john.elwell@siemens-enterprise.com Thu Apr 2 13:07:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BAD3A672F for ; Thu, 2 Apr 2009 13:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 G+tU+EKVR3+m for ; Thu, 2 Apr 2009 13:07:14 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 06FD13A695C for ; Thu, 2 Apr 2009 13:07:13 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHH00223P9NAT@siemenscomms.co.uk> for sip@ietf.org; Thu, 02 Apr 2009 21:08:11 +0100 (BST) Date: Thu, 02 Apr 2009 21:08:09 +0100 From: "Elwell, John" In-reply-to: <618e24240904010620t743f612dtf207c4efcdade223@mail.gmail.com> To: =?iso-8859-1?Q?Victor_Pascual_=C1vila?= Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001BA69F9@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Media vs Signaling identity (was Re: francois' comments andwhy RFC4474 not used in the field) Thread-Index: AcmyzMqRyX9gksLpTVGkA6km4i1iHwBAVmwA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <618e24240903310306k61cefe0cwb71848b3d78a7e50@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51BFF@GBNTHT12009MSX.gb002.siemens.net> <618e24240904010620t743f612dtf207c4efcdade223@mail.gmail.com> Cc: SIP List Subject: Re: [Sip] Media vs Signaling identity (was Re: francois' comments andwhy RFC4474 not used in the field) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:07:15 -0000 =20 > -----Original Message----- > From: Victor Pascual =C1vila [mailto:victor.pascual.avila@gmail.com]=20 > Sent: 01 April 2009 14:21 > To: Elwell, John > Cc: Jonathan Rosenberg; SIP List > Subject: Re: [Sip] Media vs Signaling identity (was Re:=20 > francois' comments andwhy RFC4474 not used in the field) >=20 > On Wed, Apr 1, 2009 at 12:33 PM, Elwell, John > wrote: > (snip) > >> While "signaling identity" seems to be a common=20 > denominator, I'm not > >> sure about the role of "media identity" in the above=20 > listed scenarios. > >> Any clarification will be appreciated. > > [JRE] These too are valid situations where the identity=20 > needs to be authenticated. Where media is involved, however,=20 > there is an additional problem of authenticating the media,=20 > and if the media is bound to the signalling, a solution for=20 > authenticating the signalling would also authenticate the=20 > media. So we either need a solution for authenticating both=20 > signalling and media together (e.g., by authenticating the=20 > signalling, the media too gets authenticated) or we need=20 > separate mechanisms. Clearly the former would be preferable. >=20 > I guess we all agree that the following scenarios are possible (please > correct me if I'm wrong): >=20 > + Only Signaling (e.g. sender-to-receiver MESSAGE ): we need to > authenticate the signaling itself. Here we are including scenarios > where user content is embedded into the signaling plane. > + Signaling and media: we need to authenticate both signaling=20 > and media planes > -+ Media is bound to the signaling (e.g. caller-to-callee > INVITE-transaction + caller-to-callee rtp stream(s)): we may need to > authenticate both signaling and media together. (BTW, I fail to see > the benefits of coupling media and control plane identities; specially > when considering Lawful Interception) > -+ Media is not bound to the signaling (e.g. 3PCC): we may need > separate mechanisms [JRE] This I am not so sure about. With DTLS-SRTP, authentication of the = media is bound to authentication of the signalling (unless you use = CA-signed certs in the endpoints for DTLS). So it seems with DTLS-SRTP = we did not consider the media originating/terminating at a different = device from signalling. >=20 > Which scenarios are we trying to cover here? > Is the receiver identity (media or signaling) as important as the > sender identity? [JRE] Yes, probably even more important in some situations. If I am = going to disclose sensitive information, I need to be sure where it will = end up. John From fluffy@cisco.com Thu Apr 2 14:49:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9BAB3A67EA for ; Thu, 2 Apr 2009 14:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4zYaeM9LNat for ; Thu, 2 Apr 2009 14:49:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E68533A67A1 for ; Thu, 2 Apr 2009 14:49:39 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2009 21:50:41 +0000 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 n32LofGQ028387; Thu, 2 Apr 2009 14:50:41 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n32Loe0Y016786; Thu, 2 Apr 2009 21:50:41 GMT From: Cullen Jennings To: Jiri Kuthan In-Reply-To: <49D400F8.4050304@iptel.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <49CE8255.4000103@iptel.org> <49D400F8.4050304@iptel.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 15:50:40 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=367; t=1238709041; x=1239573041; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=elerCUm7LvQdqa2wfCAxBu6l657+O/aMyQHmAIy+D5A=; b=kCHXa+TnEDkd8uxFV3Bf8U9nSc3IyRZwz9846FKK10kUgsu4CjfKwq8rYJ nk2F0VpEYxlaMKOImvpbZFwvZOdYPfsbiJYxsjBc3ovnIe6aANiPsz0sxPjN ei+RMaA/jL; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:49:40 -0000 On Apr 1, 2009, at 6:04 PM, Jiri Kuthan wrote: > > Therefore I would choose the opposite way and try to learn what > are the pieces for which we have a compelling need for integrity. > (either way it may be hard to set a demarcation line though). Sure, I'd be very happy to see some good work on that direction if people felt that would get us closer. From pkyzivat@cisco.com Thu Apr 2 16:20:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958DC3A6A90; Thu, 2 Apr 2009 16:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aS9keDcK80Ag; Thu, 2 Apr 2009 16:20:54 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3F9153A6832; Thu, 2 Apr 2009 16:20:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,316,1235952000"; d="scan'208";a="40856503" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Apr 2009 23:21:55 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n32NLtq2031656; Thu, 2 Apr 2009 19:21:55 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n32NLtD2009409; Thu, 2 Apr 2009 23:21:55 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 19:21:55 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 19:21:55 -0400 Message-ID: <49D54893.6010008@cisco.com> Date: Thu, 02 Apr 2009 19:21:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Keith Moore References: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> <49D4461E.2050709@cs.utk.edu> In-Reply-To: <49D4461E.2050709@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2009 23:21:55.0311 (UTC) FILETIME=[CFE05FF0:01C9B3E9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2483; t=1238714515; x=1239578515; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Proposal=20of=20Non-Sequential= 20Group=20Notion=20in=20ABNF=20w/=20a=20SIP=0A=20case |Sender:=20 |To:=20Keith=20Moore=20; bh=PeI3kt52QyeXAh3J5uEedocGElBaUBqSbKd859IejA4=; b=SK7ST/WSp0ySWS+3RZtoz7QtpKXCs3/D2fw3QlIK1CVYbDe/MKbC4fTW2S 0MrcXdVD4K30ErpImB/9fnb3BMJpi6Ev1X4tCCToV+C4zLdMcI4/9bhozZ45 HHabDWbKQC; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP@ietf.org, apps-discuss@ietf.org Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 23:20:55 -0000 I agree with Keith about the inadvisability of rewriting the grammar. Save it for SIP/3.0. In any case, I think the issue isn't with ABNF per se, its with the way ABNF was used for SIP. ABNF isn't actually able to represent everything that was desired for sip, so some things were simply handled as exceptions in the text. Of course the "right" thing to do would have been to either give up on anything that couldn't legitimately be represented, or else switch to some other specification language that could express what was intended. But there is a big tradeoff there. At least many people are capable of reading ABNF, and a reasonable number of those can accurately understand what it means. A somewhat smaller, but still significant, number can write it correctly. Its important that the people involved in the standardization process, and that implement the standard, be able to understand it. A more powerful specification language, that fewer people could understand, might not be such a great choice. Thanks, Paul Keith Moore wrote: > eburger wrote: >> Personally, I don't understand why we didn't just use YACC. > Exercise: write an RFC ?822 parse in yacc. It can be done, but not > easily, as the RFC ?822 grammar is not LALR(1). >> I am really in favor of using a formal language for specifying grammar. As Munjo states, the ABNF is essentially documentation fluff - useless at best and wrong at worst. >> >> As for this particular suggestion, I am ambivalent as to whether we hack ABNF, adopt YACC, or even adopt ASN.1. > One lesson from the DRUMS effort - rewrite an existing grammar at your > peril. Even if the old specification has errors, writing a new grammar > which verifiably recognizes exactly the same language as the old one can > be difficult. And even if you restrict the language that new > implementations can emit, you generally have to accept the old language > for compatibility's sake. So you end up with two grammars where one was > formerly (almost) good enough. > > Keith > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From munjo.yu@gmail.com Thu Apr 2 17:00:52 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3693A684C; Thu, 2 Apr 2009 17:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.618, 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 AI1pOQPj4O9T; Thu, 2 Apr 2009 17:00:51 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 8AAAE3A67B1; Thu, 2 Apr 2009 17:00:51 -0700 (PDT) Received: by qyk36 with SMTP id 36so1531351qyk.29 for ; Thu, 02 Apr 2009 17:01:53 -0700 (PDT) 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=K3BIFiZ3yHWcZBY5RX4flunI3nIsAzsxWWjsQq9dGnY=; b=oLttBrof2mQ/QfdjJR4xFGA80XlpcSMh9KcIipxeOpF1WHgryMyY+B9zuwFHNChiW+ Hp2WdWy1y/CRnoxPYr725mv03Mj9Ikqvn15t5vIWjTk35mxxR0wqq96atVTxvWsi33Lu 0K38vKw66xU+V6QfYAnBABzdVktSU0LzdD46Q= 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=fUmpl1yf3knVLnQksMXGfZCDvysBefwSooK9H3q+qW5OWGmL8bqxHSLVxTx4zlkNEy bh5ds4Jxsl55P8CodV28EZmJw6HAudF0i4YGCsFMNxtmfV22JSjmge+JCOwqFoSecJRE lVaHW6IlT1wrj0MFeXbwa2wt1Ii7QBEzjE/zI= MIME-Version: 1.0 Received: by 10.229.84.5 with SMTP id h5mr335774qcl.25.1238716913214; Thu, 02 Apr 2009 17:01:53 -0700 (PDT) In-Reply-To: <49D54E3A.4080702@cs.utk.edu> References: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> <49D4461E.2050709@cs.utk.edu> <49D54893.6010008@cisco.com> <49D54E3A.4080702@cs.utk.edu> Date: Thu, 2 Apr 2009 19:01:53 -0500 Message-ID: From: Munjo Yu To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIP@ietf.org, Paul Kyzivat , apps-discuss@ietf.org Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 00:00:52 -0000 Thanks for the historical insights. Yes, I found the following section from http://tools.ietf.org/html/draft-ietf-drums-abnf-02 3.5 Set Group: {Rule 1 Rule2} Elements enclosed in braces (squiggly brackets) are treated as a single, UNORDERED element. Its contents may occur in any order. Hence: {elem foo} bar would match (elem foo bar) and (foo elem bar). NOTE: Specifying alternatives is quite different from specifying set grouping. Alternatives indicate the matching of exactly one (sub-)rule out of the total grouping. The set mechanism indicates the matching of a string which contains all of the elements within the group; however the elements may occur in any order. And it was dropped from the following revisions. To understand the ambiguity Keith mentioned, I tried to find any discussion archives which led to the decision, but no luck so far. Anyone knows about such an archive somewhere? thanks, -Munjo On Thu, Apr 2, 2009 at 6:46 PM, Keith Moore wrote: > Paul Kyzivat wrote: >> I agree with Keith about the inadvisability of rewriting the grammar. >> Save it for SIP/3.0. >> >> In any case, I think the issue isn't with ABNF per se, its with the >> way ABNF was used for SIP. ABNF isn't actually able to represent >> everything that was desired for sip, so some things were simply >> handled as exceptions in the text. >> >> Of course the "right" thing to do would have been to either give up on >> anything that couldn't legitimately be represented, or else switch to >> some other specification language that could express what was intended. > not clear. =A0IMHO, trying to specify every aspect of detail of a protoco= l > syntax using a formal specification language can be misleading and cause > more interop failures, than a looser specification written in ABNF plus > some exceptions in the text. =A0 One reason for the additional failures > when using the precise formal specification is that you don't really > benefit from that specification unless you feed it to a program that > will automatically generate the recognizer. =A0And if you do automaticall= y > generate a recognizer from the formal specification, you often find that > it doesn't report errors in the way that you'd like, doesn't perform as > well as you want, etc. > > The trick is to design the protocol in such a way that a precise formal > syntax specification is not necessary. =A0 This implies having a certain > degree of simplicity and regularity in the protocol. >> >> But there is a big tradeoff there. At least many people are capable of >> reading ABNF, and a reasonable number of those can accurately >> understand what it means. A somewhat smaller, but still significant, >> number can write it correctly. Its important that the people involved >> in the standardization process, and that implement the standard, be >> able to understand it. A more powerful specification language, that >> fewer people could understand, might not be such a great choice. > exactly. > > Keith > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From moore@cs.utk.edu Thu Apr 2 16:45:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528633A6A9E; Thu, 2 Apr 2009 16:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PpoUm4VdFU8X; Thu, 2 Apr 2009 16:45:13 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 9A6F53A6A81; Thu, 2 Apr 2009 16:45:13 -0700 (PDT) Received: from lust.indecency.org (174-151-82-40.pools.spcsdns.net [174.151.82.40]) by m1.imap-partners.net (MOS 3.10.5-GA) with ESMTP id BMI84559 (AUTH admin@network-heretics.com); Thu, 2 Apr 2009 16:46:05 -0700 (PDT) Message-ID: <49D54E3A.4080702@cs.utk.edu> Date: Thu, 02 Apr 2009 19:46:02 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Paul Kyzivat References: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> <49D4461E.2050709@cs.utk.edu> <49D54893.6010008@cisco.com> In-Reply-To: <49D54893.6010008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Apr 2009 17:26:35 -0700 Cc: SIP@ietf.org, apps-discuss@ietf.org Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 23:45:14 -0000 Paul Kyzivat wrote: > I agree with Keith about the inadvisability of rewriting the grammar. > Save it for SIP/3.0. > > In any case, I think the issue isn't with ABNF per se, its with the > way ABNF was used for SIP. ABNF isn't actually able to represent > everything that was desired for sip, so some things were simply > handled as exceptions in the text. > > Of course the "right" thing to do would have been to either give up on > anything that couldn't legitimately be represented, or else switch to > some other specification language that could express what was intended. not clear. IMHO, trying to specify every aspect of detail of a protocol syntax using a formal specification language can be misleading and cause more interop failures, than a looser specification written in ABNF plus some exceptions in the text. One reason for the additional failures when using the precise formal specification is that you don't really benefit from that specification unless you feed it to a program that will automatically generate the recognizer. And if you do automatically generate a recognizer from the formal specification, you often find that it doesn't report errors in the way that you'd like, doesn't perform as well as you want, etc. The trick is to design the protocol in such a way that a precise formal syntax specification is not necessary. This implies having a certain degree of simplicity and regularity in the protocol. > > But there is a big tradeoff there. At least many people are capable of > reading ABNF, and a reasonable number of those can accurately > understand what it means. A somewhat smaller, but still significant, > number can write it correctly. Its important that the people involved > in the standardization process, and that implement the standard, be > able to understand it. A more powerful specification language, that > fewer people could understand, might not be such a great choice. exactly. Keith From dean.willis@softarmor.com Thu Apr 2 20:49:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD4193A694F for ; Thu, 2 Apr 2009 20:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 VpJZGDYtghAX for ; Thu, 2 Apr 2009 20:49:35 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1C6EE3A685E for ; Thu, 2 Apr 2009 20:49:35 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n333oV5k007365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2009 22:50:32 -0500 Message-Id: <4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> From: Dean Willis To: Jiri Kuthan In-Reply-To: <49D3EEAA.1080006@iptel.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 22:49:32 -0500 References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org> <49D3EEAA.1080006@iptel.org> X-Mailer: Apple Mail (2.930.3) Cc: SIP List , "Uzelac, Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 03:49:35 -0000 On Apr 1, 2009, at 5:46 PM, Jiri Kuthan wrote: > Dean Willis wrote: >> On Mar 30, 2009, at 8:03 PM, Jiri Kuthan wrote: >>> >>> There is a timing aspect in favor of placing identity in signaling >>> -- >>> I would like to know whose call is ringing before I answer (if I >>> do). >> So, we need identity in signaling, we need identity in media, and >> we need the two identity expressions to match. > > I'm personally happy with having it only in signaling. Should there > be some in media too, I would be in favor of keeping those two > separate -- I'm not a particular fan of protocol dependencies. > That's just not about aesthetic expression -- once a protocol > begins to depend on other protocol, which one possibly does not > need, the cost and adaptability decreases. Single-purpose > things without dependencies have a much sounder chance of > deployment. > So you're okay with knowing who dialed you, but not knowing who you are actually talking to? Personally, I want something that at least correlates the signaling and media streams. -- Dean From dean.willis@softarmor.com Thu Apr 2 20:55:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3A53A6982 for ; Thu, 2 Apr 2009 20:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 gEY2PTKGT952 for ; Thu, 2 Apr 2009 20:55:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 94F173A685E for ; Thu, 2 Apr 2009 20:55:29 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n333uPNH007405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2009 22:56:26 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 22:55:26 -0500 References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: 'Cullen Jennings' , "sip@ietf.org" , Paul Kyzivat , "'DRAGE, Keith \(Keith\)'" , Dan Wing , 'Francois Audet' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 03:55:30 -0000 On Apr 2, 2009, at 8:28 AM, Hadriel Kaplan wrote: > > p.s. and not all transits do change SDP, and some only change SDP in > certain circumstances (like for transcoding). > Well we certainly can't expect transcoding to be compatible with e2e crypto. So are there any legitimate use cases for requiring that the protocol supports MITM rewriting of SDP? Having a transit provider that, for unknown reasons changes SDP is still not an adequate justification. Perhaps is lots of calls started failing because they endpoints detect that a MITM attack on their signaling/media has occurred, and did so in a way that makes that failure evident to the MITM, then we'd see fewer MITMs making that mistake. -- Dean From dean.willis@softarmor.com Thu Apr 2 20:59:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8B13A69C5 for ; Thu, 2 Apr 2009 20:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 GGVCHToxDpco for ; Thu, 2 Apr 2009 20:59:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5776A3A685E for ; Thu, 2 Apr 2009 20:59:27 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3340PvT007471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2009 23:00:26 -0500 Message-Id: From: Dean Willis To: "Dwight, Timothy M (Tim)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 22:59:26 -0500 References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> <731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com> X-Mailer: Apple Mail (2.930.3) Cc: Cullen Jennings , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 03:59:28 -0000 On Apr 2, 2009, at 8:59 AM, Dwight, Timothy M (Tim) wrote: > > (*) this is a simplified argument. In practice SDP manipulation may > be > required > even in the "multiple operators sharing a common IP network" > scenario; e.g., > to support Lawful Intercept. > The IETF has chosen not to to design our protocols to enable lawful intercept, in large part because any design that enables lawful intercept also enables unlawful intercept, and one countries lawful intercept may be a another's espionage. See RFC 1984. -- Dean From dean.willis@softarmor.com Thu Apr 2 21:01:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6FD3A685E for ; Thu, 2 Apr 2009 21:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 83tI-pSYCu2k for ; Thu, 2 Apr 2009 21:01:52 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 729C33A6A0C for ; Thu, 2 Apr 2009 21:01:52 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3342p1M007492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2009 23:02:52 -0500 Message-Id: <420E8A49-A414-49AB-A5E3-25B3EC5D3A33@softarmor.com> From: Dean Willis To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D3B4070@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 23:01:51 -0500 References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> <731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D3B4070@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.930.3) Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 04:01:53 -0000 On Apr 2, 2009, at 10:38 AM, Francois Audet wrote: > >> Except we MUST have a problem, because several folks keep >> saying we do. >> >> So Cullen et. al. have been pushing us to nail down exactly >> what the problem is (and saying RFC 4474 is broken by SBCs is >> not an answer; it is a symptom). >> >> So what seems to be the problem? > > The problem is that people seem to prefer changing the SDP than > using TURN, because it is easier and more convenient. > > And what draft-wing-sip-identity-media does is show how and 4474-like > mechanism that doesn't protect the IP address can be used in > conjunction with DTLS-SRTP, to provide an adequate level of security. > > So, I'll repeat the question from a previous email: what's wrong with > draft-wing-sip-identity-media??? If I understand the argument, extending the d-w-s-i-m approach to non- DTLS media legitimizes the obfuscation of the one media identifier we do have -- the IP address. Some people seem to find this unacceptable. -- Dean From HKaplan@acmepacket.com Thu Apr 2 21:40:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40AA83A6828 for ; Thu, 2 Apr 2009 21:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxm2wcoi9L7D for ; Thu, 2 Apr 2009 21:40:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 511493A6A17 for ; Thu, 2 Apr 2009 21:40:01 -0700 (PDT) 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.340.0; Fri, 3 Apr 2009 00:41:02 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 3 Apr 2009 00:41:02 -0400 From: Hadriel Kaplan To: Dean Willis Date: Fri, 3 Apr 2009 00:40:59 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm0ECrE2H15nqvAT6iIU4HEYhAXCQAACqRw Message-ID: References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> In-Reply-To: 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 Cc: 'Cullen Jennings' , "sip@ietf.org" , Paul Kyzivat , "'DRAGE, Keith \(Keith\)'" , Dan Wing , 'Francois Audet' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 04:40:02 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, April 02, 2009 11:55 PM >=20 > Well we certainly can't expect transcoding to be compatible with e2e > crypto. Nope, and why I do not include that function as being compatible with it. = I do think some form of signaling caller-id may be useful in that case, but= clearly media identity is not possible short of speaking in pig-latin. =20 > So are there any legitimate use cases for requiring that the protocol > supports MITM rewriting of SDP? We already gave you some. But really the question can just be flipped arou= nd: is there a security property of the SDP's IP/port that you feel is impo= rtant to protect, such that we can't allow it to be changed? Do you feel a= n IP:port is an identity, or is somehow actually a secure indicator of anyt= hing? I mean there's plenty of other important things in SIP we're not pro= tecting with 4474 - maybe we should just sign the entire SIP message, just = in case. But we don't, because we know it wouldn't work in the real world,= and because most of them have little security value to protect. SDP is not "the user content", as a mime text attachment in a SIP MESSAGE o= r email would be. It is not "the prized possession" from the user. In par= ticular the indicated IP:port to send IP packets to/from is not. The IP is= not an application nor user identity; and it is spoofable, interceptable, = reputable, etc. You yourself have argued about SIP's dependence on the IP:= port in SDP being an architectural shortcoming, and here we are trying to m= ake sure it's cryptographically dependent! IPsec learned this the hard way= when it had to encapsulate itself in UDP due to the pseudoheader and NATs,= SIP learned it due to NAT's, a whole host of things may learn it in the v4= /v6 transition if it happens (oh, did we mention that as another SDP re-wri= ting case?). =20 =20 > Perhaps is lots of calls started failing because they endpoints detect > that a MITM attack on their signaling/media has occurred, and did so > in a way that makes that failure evident to the MITM, then we'd see > fewer MITMs making that mistake. If calls started failing because of 4474, I'm fairly sure it would be 4474 = that would be turned off, not the SDP re-writers. Because they're not an M= ITM attack on users or calls - it's a MITM attack on the IETF's principles.= But then again, there's no need to turn 4474 off - it can just be removed= by a MITM.=20 -hadriel From HKaplan@acmepacket.com Thu Apr 2 21:56:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833323A6B10 for ; Thu, 2 Apr 2009 21:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 leuEl03TPQ8g for ; Thu, 2 Apr 2009 21:56:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E952D3A6881 for ; Thu, 2 Apr 2009 21:56:12 -0700 (PDT) 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.340.0; Fri, 3 Apr 2009 00:57:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 3 Apr 2009 00:57:12 -0400 From: Hadriel Kaplan To: Dean Willis , Francois Audet Date: Fri, 3 Apr 2009 00:57:11 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm0ERhDXPL16rXVTwCiefIauy4HGAABX3UA Message-ID: References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> <731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D3B4070@zrc2hxm0.corp.nortel.com> <420E8A49-A414-49AB-A5E3-25B3EC5D3A33@softarmor.com> In-Reply-To: <420E8A49-A414-49AB-A5E3-25B3EC5D3A33@softarmor.com> 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 Cc: Cullen Jennings , "sip@ietf.org" , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 04:56:14 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dea= n > Willis > Sent: Friday, April 03, 2009 12:02 AM >=20 > If I understand the argument, extending the d-w-s-i-m approach to non- > DTLS media legitimizes the obfuscation of the one media identifier we > do have -- the IP address. Some people seem to find this unacceptable. If you're not using dtls-srtp, you don't have media identity - even with 44= 74. You're not losing it, because you didn't have it to begin with. That'= s the point I've been trying to make, anyway. An IP Address is not a media= identifier. It can be easily/trivially spoofed, and it can be less-trivia= lly intercepted. In that respect, sans dtls-srtp, 4474 is an Emperor with = no clothes. (no knock on 4474, because it never claimed to provide media i= dentity) For example, see: http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack-02 -hadriel From jiri@iptel.org Fri Apr 3 02:14:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C48C3A6AB6 for ; Fri, 3 Apr 2009 02:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xn6N-BCzqc51 for ; Fri, 3 Apr 2009 02:14:28 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id E7C9C3A68C7 for ; Fri, 3 Apr 2009 02:14:27 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 4FE8C1811CFF; Fri, 3 Apr 2009 11:15:29 +0200 (CEST) Message-ID: <49D50A28.7000205@iptel.org> Date: Thu, 02 Apr 2009 20:55:36 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Cullen Jennings References: <49CE8255.4000103@iptel.org> <43884D59-CC27-466C-88B0-71EA723454DA@cisco.com> In-Reply-To: <43884D59-CC27-466C-88B0-71EA723454DA@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 09:14:29 -0000 Hi Cullen, I'm not sure I understand all of the sensitivity of the cat skin peeling business :-). I'm just wondering if there are other folks who consider telling callee who is calling him by demonstrating a traceable not-worthless address important. And in particular doing so in a robust way that most likely survives ALG/SBC/evil-middlebox traversal (especially being resilient against such common things as SDP rewrites, whatever today's SIP path topology is). Or do you think this is not important or we have it or I haven't articulated the point in a sensible way? -jiri Cullen Jennings wrote: > > On Apr 1, 2009, at 12:52 AM, Dean Willis wrote: > >> >> On Mar 31, 2009, at 5:31 PM, Cullen Jennings wrote: >> >>> >>> On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: >>> >>>> >>>> I'm worried this is only a wishful thinking. While perfectly >>>> logical, still even in such constrained setups some bizzar >>>> ALGs do in my experience appear in the middle, change SDP >>>> and make thus the identity worthless. >>> >>> The thing I keep asking is can we make a list of reason why SDP and >>> headers get changes and in what scenarios they do this. I think it >>> will be hard to sort how to fix this without being clear what needs >>> to be fixed. >>> >>> For example, one of the things we might want to say is something >>> like: the Phone is behind a NAT and connects to it's proxy / >>> registrar for its' domain. That proxy/b2bua whatever mucks with >>> IP/ports in the SDP for NAT traversal. Then we could ask if 4474 is >>> broken in this case or not and what might be a good way of solving >>> the problem of having UAs behind NATs. >>> >> >> You seem to be trying to construct an argument for "why 4474 isn't >> broken" based on being able to transform every use case where RFC 4474 >> breaks to one where it doesn't, generally by mandating a different >> approach to solving problems (TURN vs, SDP fixup, for example). You >> seem to expect this to prove that RFC 4474 is fine as-is, needing no >> modification to its A/M signing. > > > No Dean. I am trying to get to what is the problem - and what I see > happening is several people trying to transform that into Jon and Cullen > are blocking work in this space which is not at all true - I would love > to see some progress in this space. > >> >> >> It might be useful to counter this with "If RFC 4474 isn't broken, why >> isn't it being deployed?" > > It's not needed in the bulk of todays deployments. Deployments using > email stye addresses are directly connecting often with mutual TLS or an > equivalently bound VPN. When enterprise B gets a call from > fluffy@a.com and it came over a TLS connection that had a certificate of > a.com, well you get something that meets B's authorization needs with > just that. For deployments using E.164 style addresses - they are pretty > much all capable of connecting in and out of the PSTN and there is no > interest in a security properties greater than what PSTN provides as > that is acceptable for most these users. This can easily be accomplished > with PAI and a transitive trust model. In fact, many of these > deployments have SP A talking to SP B talking to SP C and B explicitly > wants to hide that they used SP C instead of terminating the call > themselves. B needs to make it look like to A like B terminated the call > into the PSTN vs handing it to C. These sort of deployments require B to > look to A like the end not the middle. > >> I expect that the answer is "because users currently expect to correct >> their topological issues using SBCs instead of the tools that work >> with 4474. You might not think they have legitimate reasons for doing >> it this way, but the fact remains -- that's how they do it. > > You expect it might be one thing - fair enough, other disagree. What I > am suggesting will be the best way to make progress is to find out what > they do and what needs caused them to do it. Sure, for any problem, > there will be multiple ways to skin the cat. You are accusing me of > saying that the only way people are allowed to skin the cat is using a > potato peeler and that most people probably will not use a potato peeler > for cats no matter what I want. I am not in the slightest telling people > they have to use a potato peeler - I'm arguing that until we have some > common ground on if we are trying to peel a cat or potato or both, we > are unlikely to make progress on the best tool(s) for the job. > >> Technically correct or not, ordering this to flow out is likely to >> give you wet feet. >> >> -- >> Dean >> > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From pkyzivat@cisco.com Fri Apr 3 06:50:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C37A3A6827 for ; Fri, 3 Apr 2009 06:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.838 X-Spam-Level: X-Spam-Status: No, score=-5.838 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+kbKt4J7siJ for ; Fri, 3 Apr 2009 06:49:59 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4BE8E3A67E2 for ; Fri, 3 Apr 2009 06:49:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,319,1235952000"; d="scan'208";a="166216119" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 03 Apr 2009 13:51:02 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n33Dp2uk023804; Fri, 3 Apr 2009 06:51:02 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n33DomDS028980; Fri, 3 Apr 2009 13:51:01 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 09:50:56 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 09:50:56 -0400 Message-ID: <49D61440.9000704@cisco.com> Date: Fri, 03 Apr 2009 09:50:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hadriel Kaplan References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2009 13:50:56.0645 (UTC) FILETIME=[36888B50:01C9B463] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3015; t=1238766662; x=1239630662; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=Ss/Y7lO7LJQc+9AtXhpm6sd3342C62h/xs+MyhM9vFw=; b=E7BRRH1awlHP6+yt1fja3kuGYbtNAyBQatEjLBpsSE+qhrAzg/SrbSS5BA yk3Uu86Hdc5pjel/LIEDV4rhjN8WjwIY3jARC3h2vvKhgAERkaxItgllV3j8 Q86xt2fbin; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Cullen Jennings' , "sip@ietf.org" , 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , Dan Wing , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 13:50:00 -0000 RFC 4117 shows how to do transcoding in a way that doesn't introduce a MiTM. It does put more burden on the endpoints, and it does mean that the SPs must allow arbitrary media types to flow between the endpoints, but if we wanted real media security that is what we would do. And of course it only *formally* removes the MiTM. It still depends on one end or the other trusting (and vouching for) the transcoding service. Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Thursday, April 02, 2009 11:55 PM >> >> Well we certainly can't expect transcoding to be compatible with e2e >> crypto. > > Nope, and why I do not include that function as being compatible with it. I do think some form of signaling caller-id may be useful in that case, but clearly media identity is not possible short of speaking in pig-latin. > > >> So are there any legitimate use cases for requiring that the protocol >> supports MITM rewriting of SDP? > > We already gave you some. But really the question can just be flipped around: is there a security property of the SDP's IP/port that you feel is important to protect, such that we can't allow it to be changed? Do you feel an IP:port is an identity, or is somehow actually a secure indicator of anything? I mean there's plenty of other important things in SIP we're not protecting with 4474 - maybe we should just sign the entire SIP message, just in case. But we don't, because we know it wouldn't work in the real world, and because most of them have little security value to protect. > > SDP is not "the user content", as a mime text attachment in a SIP MESSAGE or email would be. It is not "the prized possession" from the user. In particular the indicated IP:port to send IP packets to/from is not. The IP is not an application nor user identity; and it is spoofable, interceptable, reputable, etc. You yourself have argued about SIP's dependence on the IP:port in SDP being an architectural shortcoming, and here we are trying to make sure it's cryptographically dependent! IPsec learned this the hard way when it had to encapsulate itself in UDP due to the pseudoheader and NATs, SIP learned it due to NAT's, a whole host of things may learn it in the v4/v6 transition if it happens (oh, did we mention that as another SDP re-writing case?). > > >> Perhaps is lots of calls started failing because they endpoints detect >> that a MITM attack on their signaling/media has occurred, and did so >> in a way that makes that failure evident to the MITM, then we'd see >> fewer MITMs making that mistake. > > If calls started failing because of 4474, I'm fairly sure it would be 4474 that would be turned off, not the SDP re-writers. Because they're not an MITM attack on users or calls - it's a MITM attack on the IETF's principles. But then again, there's no need to turn 4474 off - it can just be removed by a MITM. > > -hadriel > From john.elwell@siemens-enterprise.com Fri Apr 3 07:22:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749363A679C for ; Fri, 3 Apr 2009 07:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 gOGmctO5j9Vj for ; Fri, 3 Apr 2009 07:22:43 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 5DEA53A69AB for ; Fri, 3 Apr 2009 07:22:43 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHJ00L0R3S1GG@siemenscomms.co.uk> for sip@ietf.org; Fri, 03 Apr 2009 15:20:54 +0100 (BST) Date: Fri, 03 Apr 2009 15:20:36 +0100 From: "Elwell, John" To: SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001BA6DC5@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: My take on where we are with Identity Thread-Index: Acm0Z1uTX3b7Jrh3RD+gEvgyshIbQA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Sip] My take on where we are with Identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:22:44 -0000 >From discussions during and since IETF 74, I see that the problem space might be divided up as follows. Problem 1. Securing a call and its media. I need to know where a call and its secure media have come from or where they have gone to, i.e., the party I am talking to, the party I am exchange session-based IM or files with. I need to know the domain of that other party, and perhaps also the identity of the party itself. For some cases, I might just need to know that the other party is an agent of a particular enterprise, whereas in other cases I need to know the particular user. I want the assertion of identity to come from an entity I trust to be able to make that assertion, which in many situations rules out intermediate domains that happen to be on the path of the call. RFC 4474, in conjunction with DTLS-SRTP for real-time media and equivalents for other media, solves that problem, except where there are intermediate domains that modify signed parts of the SIP request, in particular the SDP port/address. We have NAT traversal, media steering, topology hiding, etc. as reasons the SDP gets modified. We have a divergence of opinion on which are these happen in practice, which of these are legitimate and whether we can somehow induce the proponents of these practices to clean up their act. I would say a majority of people accept that such changes do take place in practice, and some of those people accept that, whether or not these changes are legitimate, we will not be able to persuade people to stop. I think people accept that, if the media is secured (e.g., by SRTP), the signing of the IP address and port in SDP adds no security value. Proposals from Dan Wing and Kai Fischer both seem to solve this particular problem. 2. As above, but with unsecured media. We have a divergence of opinion whether there is value in RFC 4474 signing the IP address and port for media, when the media itself is not secured. I subscribe to the view that it adds very little value, for reasons Hadriel has stated several times. Therefore I don't think the practice of intermediaries changing the IP address and port is a problem worth solving. 3. Delivery of SIP messages with content not related to calls (e.g., MESSAGE, SUBSCRIBE, NOTIFY and PUBLISH requests). I just need to be sure where the content comes from. RFC 4474 provides a solution to this, although again it won't work through intermediaries that change signed parts of the request. However, such requests (unless they happen to be call-related requests that also deliver other content) do not contain SDP and are often not passed through intermediate domains in the same way that call-related requests (such as INVITE) are, so RFC 4474 might be a sufficient solution as it stands. Therefore do we need two separate solutions: one for securing signalling to the extent necessary to authenticate the certs used for media security (with a reasonable level of replay protection); and RFC 4474 as it stands for protecting a substantial part of a request? The two solutions could be used together where appropriate. John =20 From dean.willis@softarmor.com Fri Apr 3 07:47:07 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2895E3A6E54 for ; Fri, 3 Apr 2009 07:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLbJSnmrtrQb for ; Fri, 3 Apr 2009 07:47:06 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1BFF23A6CC8 for ; Fri, 3 Apr 2009 07:44:02 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n33EisSO012169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 3 Apr 2009 09:44:55 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 09:43:56 -0500 References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: 'Cullen Jennings' , "sip@ietf.org" , Paul Kyzivat , "'DRAGE, Keith \(Keith\)'" , Dan Wing , 'Francois Audet' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:47:07 -0000 On Apr 2, 2009, at 11:40 PM, Hadriel Kaplan wrote: > > > >> So are there any legitimate use cases for requiring that the protocol >> supports MITM rewriting of SDP? > > We already gave you some. I believe Cullen and Jon are arguing that no, you haven't -- you have just made the same non-examples 50 different ways. I know you want to do media-steering and see this as self evident. They want to know why media-steering requires SDP editing. I believe they think we need to make a more fundamental change to support media-steering instead of just hacking on the SDP. > But really the question can just be flipped around: is there a > security property of the SDP's IP/port that you feel is important to > protect, such that we can't allow it to be changed? Do you feel an > IP:port is an identity, or is somehow actually a secure indicator of > anything? I mean there's plenty of other important things in SIP > we're not protecting with 4474 - maybe we should just sign the > entire SIP message, just in case. But we don't, because we know it > wouldn't work in the real world, and because most of them have > little security value to protect. > Simple rational conservatism says just change something that isn't broken. Good enjoying practice says don't change something that appears to be broken until you understand the real requirements. Medical practice teaches us to treat the cause, not the symptom. Is the need to edit SDP a cause or a symptom? To me, it looks like it just might be a symptom of a more severe condition. > >> Perhaps is lots of calls started failing because they endpoints >> detect >> that a MITM attack on their signaling/media has occurred, and did so >> in a way that makes that failure evident to the MITM, then we'd see >> fewer MITMs making that mistake. > > If calls started failing because of 4474, I'm fairly sure it would > be 4474 that would be turned off, not the SDP re-writers. Because > they're not an MITM attack on users or calls - it's a MITM attack on > the IETF's principles. But then again, there's no need to turn 4474 > off - it can just be removed by a MITM. If users start to refuse carrier services because the carrier's SBC- riddled architectures can't support the users security requirements, carriers will either fix their architectures or go broke. Historically, many of them would rather go broke than fix their architecture, and I'm okay with that. -- Dean From victor.pascual.avila@gmail.com Fri Apr 3 08:08:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC2D3A69AB for ; Fri, 3 Apr 2009 08:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.035, 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 lvf7FkOdbJFr for ; Fri, 3 Apr 2009 08:08:44 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 859973A683A for ; Fri, 3 Apr 2009 08:08:43 -0700 (PDT) Received: by ewy9 with SMTP id 9so1021288ewy.37 for ; Fri, 03 Apr 2009 08:09:43 -0700 (PDT) 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=oIwhFoE+0AwxrZck7HMdyllvAZeIgBmCiLWHL4VAZPc=; b=qPMjWt7J785OV/5SIeJt0GxhGxpc+7CRIHvi5GmtWUoLVfKKwLGhmW2e2VDG4hkhh3 3RyAXYqBIToN1H5HmiBn+IqwW7uZWQ7gIEe4AVnVRloC7jX6kCC7xM236ReOhyZg3410 uU/yWlck1YNGfzNKh7cghnNNaDGyoB5KvK/sg= 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=PRql7DOywC4L2mhqv+rOd175s2wnTxilnTjr+YOjnk2CnISumox+IyfNuQhpLCxHmC BdRyWGQGGihwphn6cJiSHQNHTUBgkYu2+Wgkm21l6uufzclexXzWFC6+uoT/7IUDbss3 LSzB7hcCAMIzkZh6KTlhCMznATQCvKSmcaUAc= MIME-Version: 1.0 Received: by 10.210.54.15 with SMTP id c15mr979820eba.68.1238771383360; Fri, 03 Apr 2009 08:09:43 -0700 (PDT) In-Reply-To: References: <49CE8255.4000103@iptel.org> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> Date: Fri, 3 Apr 2009 17:09:43 +0200 Message-ID: <618e24240904030809y6a36d388g979e9176bf2d1303@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Dean Willis Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "sip@ietf.org" , Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Dan Wing , Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:08:44 -0000 On Fri, Apr 3, 2009 at 5:55 AM, Dean Willis wro= te: > So are there any legitimate use cases for requiring that the protocol > supports MITM rewriting of SDP? Today, rewriting SDP bodies to convey QoS information to the terminals might be a valid use case (e.g. "group several flows into a single QoS reservation flow"). Anyway, one could expect that mechanisms like draft-ietf-sip-session-policy-framework will become adopted in a near future. --=20 Victor Pascual =C3=81vila From AUDET@nortel.com Fri Apr 3 08:21:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349AA3A6AFB for ; Fri, 3 Apr 2009 08:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MZNV2G7BbaV for ; Fri, 3 Apr 2009 08:20:59 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2908A3A6A58 for ; Fri, 3 Apr 2009 08:20:59 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n33FLOV25672; Fri, 3 Apr 2009 15:21:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 10:21:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D3F75CE@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm0EC9IeKajn0vvRs2GzboET62NRwAX6FNQ References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> From: "Francois Audet" To: "Dean Willis" , "Hadriel Kaplan" Cc: Cullen Jennings , sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(Keith\)" , Dan Wing Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:21:00 -0000 Obviously, if you want a transcoding service, then you can't you e2e security. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, April 02, 2009 20:55 > To: Hadriel Kaplan > Cc: Paul Kyzivat; 'Cullen Jennings'; sip@ietf.org; Audet,=20 > Francois (SC100:3055); 'DRAGE, Keith (Keith)'; Dan Wing > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > On Apr 2, 2009, at 8:28 AM, Hadriel Kaplan wrote: >=20 > > > > p.s. and not all transits do change SDP, and some only=20 > change SDP in=20 > > certain circumstances (like for transcoding). > > >=20 > Well we certainly can't expect transcoding to be compatible with e2e =20 > crypto. >=20 > So are there any legitimate use cases for requiring that the=20 > protocol =20 > supports MITM rewriting of SDP? >=20 > Having a transit provider that, for unknown reasons changes SDP is =20 > still not an adequate justification. >=20 > Perhaps is lots of calls started failing because they=20 > endpoints detect =20 > that a MITM attack on their signaling/media has occurred, and did so =20 > in a way that makes that failure evident to the MITM, then we'd see =20 > fewer MITMs making that mistake. >=20 > -- > Dean >=20 From HKaplan@acmepacket.com Fri Apr 3 08:49:37 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC7C3A6D60 for ; Fri, 3 Apr 2009 08:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 lkVqJycHaCNc for ; Fri, 3 Apr 2009 08:49:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 000983A6C41 for ; Fri, 3 Apr 2009 08:49:36 -0700 (PDT) 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.340.0; Fri, 3 Apr 2009 11:50:38 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 3 Apr 2009 11:50:38 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?Victor_Pascual_=C1vila?= , Dean Willis Date: Fri, 3 Apr 2009 11:50:37 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm0bkWGNsks0h+1TJyNKhnUVyWKtgABYn2Q Message-ID: References: <49CE8255.4000103@iptel.org> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> <618e24240904030809y6a36d388g979e9176bf2d1303@mail.gmail.com> In-Reply-To: <618e24240904030809y6a36d388g979e9176bf2d1303@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cullen Jennings , "sip@ietf.org" , Kyzivat , "DRAGE, Keith \(Keith\)" , Dan Wing , Paul, Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:49:37 -0000 > -----Original Message----- > From: Victor Pascual =C1vila [mailto:victor.pascual.avila@gmail.com] > Sent: Friday, April 03, 2009 11:10 AM > > Anyway, one could expect that mechanisms like > draft-ietf-sip-session-policy-framework will become adopted in a near > future. You are refreshingly optimistic. :) -hadriel From dwing@cisco.com Fri Apr 3 08:49:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFD13A6A07 for ; Fri, 3 Apr 2009 08:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.984 X-Spam-Level: X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wri+e+SxPTIS for ; Fri, 3 Apr 2009 08:49:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4866C3A67BD for ; Fri, 3 Apr 2009 08:49:44 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2009 15:50:47 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n33FolZk011785; Fri, 3 Apr 2009 08:50:47 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n33Fok32015543; Fri, 3 Apr 2009 15:50:46 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Dean Willis'" References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904010723n53a3fb99kc349598c3322337a@mail.gmail.com> <033b01c9b2ed$c95d2d90$c4f0200a@cisco.com> <0B179D25-17A1-40E0-88C6-276C9A040DC6@softarmor.com> <038701c9b2f3$b88300c0$c4f0200a@cisco.com> <49D3B493.4050101@cisco.com> Date: Fri, 3 Apr 2009 08:50:46 -0700 Message-ID: <0b6001c9b473$f4506d00$c4f0200a@cisco.com> 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: Acm0ECrE2H15nqvAT6iIU4HEYhAXCQAACqRwABh49RA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3601; t=1238773847; x=1239637847; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=65+36g4hjdSulBMawvT9TeX/CFbIgwl0Rc9qXvk+cJA=; b=E00jMKzKZmNztHvMgJik8zqo596XC1S5lyI/UYbckawoOYIMMMdYlaTgJM JBGUCWx7a3JuRaMDvvXxvtCQpuPFDsI86f/uUgGPzE1H0B0Nsrmcn0FCrBeS f5UYsgwj+l; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Cullen Jennings' , sip@ietf.org, 'Paul Kyzivat' , "'DRAGE, Keith \(Keith\)'" , 'Francois Audet' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:49:45 -0000 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Thursday, April 02, 2009 11:55 PM > > > > Well we certainly can't expect transcoding to be compatible with e2e > > crypto. > > Nope, and why I do not include that function as being > compatible with it. I do think some form of signaling > caller-id may be useful in that case, but clearly media > identity is not possible short of speaking in pig-latin. It is true that we cannot provide edge-to-edge *authenticated* media through a transcoder when that transcoder is operated by someone other than an edge. That is because e2e authenticated media is keyed with DTLS-SRTP, which we would only trust edge-to-edge. But we can provide __identity__ over the media path, even with transcoding. Identity across a transcoder only requires the transcoding function allows the identity through. AS AN EXAMPLE, if we used the ICE technique in http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4.3, the transcoder could permit the ICE messages to pass, unmolested and unmodified, across the transcoder. The transcoder would perform its normal transcoding function with the RTP packets. I am saying "as an example" because we may not want to use ICE for this purpose; I have other ideas for how this might be done which may be more appealing. -d > > So are there any legitimate use cases for requiring that > > the protocol supports MITM rewriting of SDP? > > We already gave you some. But really the question can just > be flipped around: is there a security property of the SDP's > IP/port that you feel is important to protect, such that we > can't allow it to be changed? Do you feel an IP:port is an > identity, or is somehow actually a secure indicator of > anything? > > I mean there's plenty of other important things in > SIP we're not protecting with 4474 - maybe we should just > sign the entire SIP message, just in case. But we don't, > because we know it wouldn't work in the real world, and > because most of them have little security value to protect. > > SDP is not "the user content", as a mime text attachment in a > SIP MESSAGE or email would be. It is not "the prized > possession" from the user. In particular the indicated > IP:port to send IP packets to/from is not. The IP is not an > application nor user identity; and it is spoofable, > interceptable, reputable, etc. You yourself have argued > about SIP's dependence on the IP:port in SDP being an > architectural shortcoming, and here we are trying to make > sure it's cryptographically dependent! IPsec learned this > the hard way when it had to encapsulate itself in UDP due to > the pseudoheader and NATs, SIP learned it due to NAT's, a > whole host of things may learn it in the v4/v6 transition if > it happens (oh, did we mention that as another SDP re-writing > case?). > > > Perhaps is lots of calls started failing because they > > endpoints detect > > that a MITM attack on their signaling/media has occurred, and did so > > in a way that makes that failure evident to the MITM, then we'd see > > fewer MITMs making that mistake. > > If calls started failing because of 4474, I'm fairly sure it > would be 4474 that would be turned off, not the SDP > re-writers. Because they're not an MITM attack on users or > calls - it's a MITM attack on the IETF's principles. But > then again, there's no need to turn 4474 off - it can just be > removed by a MITM. > > -hadriel From AUDET@nortel.com Fri Apr 3 09:23:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8423A6C23 for ; Fri, 3 Apr 2009 09:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyiNyn9KP+MC for ; Fri, 3 Apr 2009 09:23:14 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9742D3A6D41 for ; Fri, 3 Apr 2009 09:22:55 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n33GNRa13865; Fri, 3 Apr 2009 16:23:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 11:22:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D3F77C5@zrc2hxm0.corp.nortel.com> In-Reply-To: <420E8A49-A414-49AB-A5E3-25B3EC5D3A33@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm0ERR4TjstvTSATtSpSxPIiUjaGQAZx9GA References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> <731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D3B4070@zrc2hxm0.corp.nortel.com> <420E8A49-A414-49AB-A5E3-25B3EC5D3A33@softarmor.com> From: "Francois Audet" To: "Dean Willis" Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:23:15 -0000 =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, April 02, 2009 21:02 > To: Audet, Francois (SC100:3055) > Cc: Dwight, Timothy M (Tim); Cullen Jennings; sip@ietf.org;=20 > DRAGE, Keith (Keith) > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field > > > And what draft-wing-sip-identity-media does is show how and=20 > 4474-like=20 > > mechanism that doesn't protect the IP address can be used in=20 > > conjunction with DTLS-SRTP, to provide an adequate level of=20 > security. > > > > So, I'll repeat the question from a previous email: what's=20 > wrong with=20 > > draft-wing-sip-identity-media??? >=20 > If I understand the argument, extending the d-w-s-i-m=20 > approach to non- DTLS media legitimizes the obfuscation of=20 > the one media identifier we do have -- the IP address. Some=20 > people seem to find this unacceptable. No, that's not what I'm saying. I'm saying draft-wing-sip-identity-media WITH DTLS-SRTP. ^^^^ What's wrong with that approach? Unless I'm missing something, it does seem to achieve end-to-end media and identity security. From dwing@cisco.com Fri Apr 3 10:21:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5738228C11C for ; Fri, 3 Apr 2009 10:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2aQR+HbRhMh for ; Fri, 3 Apr 2009 10:21:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 845A53A6859 for ; Fri, 3 Apr 2009 10:21:42 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Apr 2009 17:22:45 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n33HMjQe025787; Fri, 3 Apr 2009 10:22:45 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n33HMjtC007706; Fri, 3 Apr 2009 17:22:45 GMT From: "Dan Wing" To: "'Dean Willis'" , "'Jiri Kuthan'" References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org> <4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> Date: Fri, 3 Apr 2009 10:22:45 -0700 Message-ID: <0be201c9b480$cd88adb0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm0D2BNqKkc1QEORcmKWXlYOHokvwAcWepQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1668; t=1238779365; x=1239643365; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=9X3+KnXgUHIlQbfOH7vklBzm/pOkuIAZsn+5GAXNAjQ=; b=HjklXAggeoy2HoHx1f5OTIGcfzj7zTA8ePLIfzstQshqj1cvMDQXHKCQ3M XSju0RzCzkK+0L0SI2Z88Hd9WNX+jf2x1CmkRaKDHOB0QICKXIlW8PNtpjEK aQiTsioE/6; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'SIP List' , "'Uzelac, Adam'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:21:43 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Thursday, April 02, 2009 8:50 PM > To: Jiri Kuthan > Cc: SIP List; Uzelac, Adam > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > On Apr 1, 2009, at 5:46 PM, Jiri Kuthan wrote: > > > Dean Willis wrote: > >> On Mar 30, 2009, at 8:03 PM, Jiri Kuthan wrote: > >>> > >>> There is a timing aspect in favor of placing identity in > signaling > >>> -- > >>> I would like to know whose call is ringing before I answer (if I > >>> do). > >> So, we need identity in signaling, we need identity in media, and > >> we need the two identity expressions to match. > > > > I'm personally happy with having it only in signaling. Should there > > be some in media too, I would be in favor of keeping those two > > separate -- I'm not a particular fan of protocol dependencies. > > That's just not about aesthetic expression -- once a protocol > > begins to depend on other protocol, which one possibly does not > > need, the cost and adaptability decreases. Single-purpose > > things without dependencies have a much sounder chance of > > deployment. > > > > So you're okay with knowing who dialed you, but not knowing who you > are actually talking to? > > Personally, I want something that at least correlates the signaling > and media streams. All 5 techniques described in http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4 accomplish that using TLS, DTLS-SRTP, ICE, HIP, or ZRTP -- any of those choices has different tradeoffs. -d From dwing@cisco.com Fri Apr 3 10:23:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7058A28C11C for ; Fri, 3 Apr 2009 10:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4gVVWcSQRPw for ; Fri, 3 Apr 2009 10:23:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9F04A3A6A78 for ; Fri, 3 Apr 2009 10:23:11 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2009 17:24:14 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n33HOEer015988; Fri, 3 Apr 2009 10:24:14 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n33HOE1t009442; Fri, 3 Apr 2009 17:24:14 GMT From: "Dan Wing" To: "'Dean Willis'" , "'Francois Audet'" References: <49CE8255.4000103@iptel.org><28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net><32590116-67B7-4C23-8159-7991372972EF@softarmor.com><731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com><1ECE0EB50388174790F9694F77522CCF1D3B4070@zrc2hxm0.corp.nortel.com> <420E8A49-A414-49AB-A5E3-25B3EC5D3A33@softarmor.com> Date: Fri, 3 Apr 2009 10:24:14 -0700 Message-ID: <0be301c9b481$02addf60$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <420E8A49-A414-49AB-A5E3-25B3EC5D3A33@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm0ERU0k4FYKp94QE24KeM1Ovj1bAAb8pLQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1701; t=1238779454; x=1239643454; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=mmwoIFywoTY0mljEPJj96MHer1khTIjWlkK7DGSxAR0=; b=tlGdp8KJIfstrRK0UxKCDMLDTSN6Fqr8vAHrWGMydUQEVnbDM79sEl5K2a eF4wa6ypgEGdcCnMiwEtLBjW7lxFnmtFXfa1EZ6IEPQLwmw9Omcxdzu1HAwb pTFlC1GEBi; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Cullen Jennings' , sip@ietf.org, "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:23:14 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Thursday, April 02, 2009 9:02 PM > To: Francois Audet > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > On Apr 2, 2009, at 10:38 AM, Francois Audet wrote: > > > > >> Except we MUST have a problem, because several folks keep > >> saying we do. > >> > >> So Cullen et. al. have been pushing us to nail down exactly > >> what the problem is (and saying RFC 4474 is broken by SBCs is > >> not an answer; it is a symptom). > >> > >> So what seems to be the problem? > > > > The problem is that people seem to prefer changing the SDP than > > using TURN, because it is easier and more convenient. > > > > And what draft-wing-sip-identity-media does is show how and > 4474-like > > mechanism that doesn't protect the IP address can be used in > > conjunction with DTLS-SRTP, to provide an adequate level of > security. > > > > So, I'll repeat the question from a previous email: what's > wrong with > > draft-wing-sip-identity-media??? > > If I understand the argument, extending the d-w-s-i-m > approach to non- > DTLS media legitimizes the obfuscation of the one media > identifier we > do have -- the IP address. Nope, it doesn't. draft-wing-sip-identity-media uses the media path to prove it is the same entity as indicated in the SIP signaling path. Hence the name "SIP Identity Media". > Some people seem to find this unacceptable. It would be objectionable, if SIP Identity Media did that. It doesn't. -d From AUDET@nortel.com Fri Apr 3 10:24:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB46A3A6965 for ; Fri, 3 Apr 2009 10:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJJDN4dDUscG for ; Fri, 3 Apr 2009 10:24:21 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B7BF63A68F6 for ; Fri, 3 Apr 2009 10:24:20 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n33HPDa14642; Fri, 3 Apr 2009 17:25:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 12:25:08 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> In-Reply-To: <0be201c9b480$cd88adb0$c4f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm0D2BNqKkc1QEORcmKWXlYOHokvwAcWepQAAAPoSA= References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> From: "Francois Audet" To: "Dan Wing" , "Dean Willis" , "Jiri Kuthan" Cc: SIP List , "Uzelac,Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:24:21 -0000 =20 > All 5 techniques described in > http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4 > accomplish that using TLS, DTLS-SRTP, ICE, HIP, or ZRTP --=20 > any of those choices has different tradeoffs. I'm puzzled by why we would do anything but the DTLS-SRTP (and TLS for = TCP traffic). From dwing@cisco.com Fri Apr 3 10:25:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332CD28C11C for ; Fri, 3 Apr 2009 10:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pSYkIcopWfd for ; Fri, 3 Apr 2009 10:25:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 983B13A68F6 for ; Fri, 3 Apr 2009 10:25:10 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 03 Apr 2009 17:26:13 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n33HQD2f020015; Fri, 3 Apr 2009 10:26:13 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n33HQDG5022575; Fri, 3 Apr 2009 17:26:13 GMT From: "Dan Wing" To: "'Elwell, John'" , "'SIP List'" References: <0D5F89FAC29E2C41B98A6A762007F5D001BA6DC5@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 3 Apr 2009 10:26:13 -0700 Message-ID: <0bea01c9b481$4993be90$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001BA6DC5@GBNTHT12009MSX.gb002.siemens.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm0Z1uTX3b7Jrh3RD+gEvgyshIbQAAGep6Q DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3910; t=1238779573; x=1239643573; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20My=20take=20on=20where=20we=20a re=20with=20Identity |Sender:=20; bh=DRNna4f+b2uBO1wO6NrsD+opD0SFU2YPUqaVELV4/Vg=; b=NZcLhyoQGZSAFAa7103iJ4bMYWH8AhHB6geAZL1zEnxHELew+TKTTPvs1u cmDzWQIX0FAGTcmmIA2VwyiSe4kJSNTh5KJZRiyV0J5wzxhE4SaxVqeO/0c7 9F5zhP0RjN; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Sip] My take on where we are with Identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:25:16 -0000 Good summary. Thanks. -d > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Friday, April 03, 2009 7:21 AM > To: SIP List > Subject: [Sip] My take on where we are with Identity > > From discussions during and since IETF 74, I see that the > problem space > might be divided up as follows. > > Problem 1. Securing a call and its media. I need to know where a call > and its secure media have come from or where they have gone to, i.e., > the party I am talking to, the party I am exchange session-based IM or > files with. I need to know the domain of that other party, and perhaps > also the identity of the party itself. For some cases, I > might just need > to know that the other party is an agent of a particular enterprise, > whereas in other cases I need to know the particular user. I want the > assertion of identity to come from an entity I trust to be > able to make > that assertion, which in many situations rules out > intermediate domains > that happen to be on the path of the call. > > RFC 4474, in conjunction with DTLS-SRTP for real-time media and > equivalents for other media, solves that problem, except > where there are > intermediate domains that modify signed parts of the SIP request, in > particular the SDP port/address. We have NAT traversal, media > steering, > topology hiding, etc. as reasons the SDP gets modified. We have a > divergence of opinion on which are these happen in practice, which of > these are legitimate and whether we can somehow induce the > proponents of > these practices to clean up their act. I would say a majority > of people > accept that such changes do take place in practice, and some of those > people accept that, whether or not these changes are > legitimate, we will > not be able to persuade people to stop. I think people accept that, if > the media is secured (e.g., by SRTP), the signing of the IP > address and > port in SDP adds no security value. > > Proposals from Dan Wing and Kai Fischer both seem to solve this > particular problem. > > 2. As above, but with unsecured media. We have a divergence of opinion > whether there is value in RFC 4474 signing the IP address and port for > media, when the media itself is not secured. I subscribe to the view > that it adds very little value, for reasons Hadriel has stated several > times. Therefore I don't think the practice of intermediaries changing > the IP address and port is a problem worth solving. > > 3. Delivery of SIP messages with content not related to calls (e.g., > MESSAGE, SUBSCRIBE, NOTIFY and PUBLISH requests). I just need > to be sure > where the content comes from. RFC 4474 provides a solution to this, > although again it won't work through intermediaries that change signed > parts of the request. However, such requests (unless they happen to be > call-related requests that also deliver other content) do not contain > SDP and are often not passed through intermediate domains in the same > way that call-related requests (such as INVITE) are, so RFC 4474 might > be a sufficient solution as it stands. > > Therefore do we need two separate solutions: one for securing > signalling > to the extent necessary to authenticate the certs used for media > security (with a reasonable level of replay protection); and > RFC 4474 as > it stands for protecting a substantial part of a request? The two > solutions could be used together where appropriate. > > John > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From dwing@cisco.com Fri Apr 3 10:43:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD5828C138 for ; Fri, 3 Apr 2009 10:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbmkkG8EEaet for ; Fri, 3 Apr 2009 10:43:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6995C3A6D6A for ; Fri, 3 Apr 2009 10:43:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,320,1235952000"; d="scan'208";a="166345724" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 03 Apr 2009 17:44:25 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n33HiPr2000954; Fri, 3 Apr 2009 10:44:25 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n33HiP0B012116; Fri, 3 Apr 2009 17:44:25 GMT From: "Dan Wing" To: "'Francois Audet'" , "'Dean Willis'" , "'Jiri Kuthan'" References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> Date: Fri, 3 Apr 2009 10:44:25 -0700 Message-ID: <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm0D2BNqKkc1QEORcmKWXlYOHokvwAcWepQAAAPoSAAAI6WwA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=731; t=1238780665; x=1239644665; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=MFLDsSSr69RR74WgEcvN1EDVXnHv9P0Ws6sY4uPA+G8=; b=A5pmg1dil1V1w/yAKO1lHM6WOC7/03azXoJLlIcFXrrMYwFvr8sz3EmnhO HjLwWVr2VMUAQFaWYDjcLUPk051Ge6ZeGBLf4KCa41DD6VE3b2grV5liJOoa ZqnGpWzuaV; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'SIP List' , "'Uzelac, Adam'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:43:23 -0000 > > All 5 techniques described in > > > http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4 > > accomplish that using TLS, DTLS-SRTP, ICE, HIP, or ZRTP -- > > any of those choices has different tradeoffs. > > I'm puzzled by why we would do anything but the DTLS-SRTP > (and TLS for TCP traffic). I also prefer TLS. RFC4474 doesn't require TLS, so ICE is in the draft to demonstrate it is possible to have identity even through a translator and have identity with just RTP (RFC4474 provides identity with just RTP). However, if we used TLS/DTLS-SRTP for identity it would (a) break transcoding (as discussed) and (b) require deploying SRTP. If doubt we are willing to do (a) and (b). -d From AUDET@nortel.com Fri Apr 3 13:46:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455BA28C121 for ; Fri, 3 Apr 2009 13:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF+LhiVL17xq for ; Fri, 3 Apr 2009 13:46:34 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 32A1428C116 for ; Fri, 3 Apr 2009 13:46:34 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n33KlUa12812; Fri, 3 Apr 2009 20:47:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 15:47:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> In-Reply-To: <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm0D2BNqKkc1QEORcmKWXlYOHokvwAcWepQAAAPoSAAAI6WwAAAM80g References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> From: "Francois Audet" To: "Dan Wing" , "Dean Willis" , "Jiri Kuthan" Cc: SIP List , "Uzelac,Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:46:35 -0000 I'm not sure I agree with the logic. It seems to me when e2e security of media, then DTS-SRTP (for UDP) and = TLS (for TCP) makes perfect sense. If we allow transcoding, then I don't see the point in e2e security, = since it obviously is not e2e. I don't understand what ICE gives you in this = case. If we need transcoding, then we might want instead to have a security = mechanism with the transcoder instead. For example, we could use DTLS-SRTP where Alice is using the 4474-like = mechanism, but the transcoder is using it's own cert (instead of a self-signed = one). That cert's credentials would already be provisioned in Alice's device. That = would=20 seem like a simple way to do this. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Friday, April 03, 2009 10:44 > To: Audet, Francois (SC100:3055); 'Dean Willis'; 'Jiri Kuthan' > Cc: 'SIP List'; 'Uzelac,Adam' > Subject: RE: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 > > > All 5 techniques described in > > >=20 > >=20 > http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4 > > > accomplish that using TLS, DTLS-SRTP, ICE, HIP, or ZRTP -- any of=20 > > > those choices has different tradeoffs. > >=20 > > I'm puzzled by why we would do anything but the DTLS-SRTP=20 > (and TLS for=20 > > TCP traffic). >=20 > I also prefer TLS. RFC4474 doesn't require TLS, so ICE is in=20 > the draft to demonstrate it is possible to have identity even=20 > through a translator and have identity with just RTP (RFC4474=20 > provides identity with just RTP). >=20 > However, if we used TLS/DTLS-SRTP for identity it would (a)=20 > break transcoding (as discussed) and (b) require deploying=20 > SRTP. If doubt we are willing to do > (a) and (b). >=20 > -d >=20 >=20 From dwing@cisco.com Fri Apr 3 14:09:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0853A67AE for ; Fri, 3 Apr 2009 14:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oFjc16h3KnX for ; Fri, 3 Apr 2009 14:09:09 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 876713A6C38 for ; Fri, 3 Apr 2009 14:09:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,321,1235952000"; d="scan'208";a="150190381" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 03 Apr 2009 21:10:03 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n33LA3Ao013089; Fri, 3 Apr 2009 14:10:03 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n33LA3ej029698; Fri, 3 Apr 2009 21:10:03 GMT From: "Dan Wing" To: "'Francois Audet'" , "'Dean Willis'" , "'Jiri Kuthan'" References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> Date: Fri, 3 Apr 2009 14:10:03 -0700 Message-ID: <0d0901c9b4a0$8e5fa650$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm0D2BNqKkc1QEORcmKWXlYOHokvwAcWepQAAAPoSAAAI6WwAAAM80gAAbqKoA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2853; t=1238793003; x=1239657003; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=ZGmIulSbfIkBfpeLiLkrre5596nLgKm2R3rnkNfxnXE=; b=ZCeE0lDZler7qTH3yDzc1NFFLFZAzMRx/pKK2SAAK6s+kpOcMq2J2VZha4 aQ7gs8zP4tpIuR9bSN5ta1wR1rW6Om2Hdneq1kNQdKFLjtEP1LRPsVn6//8n 5/vSEIO9s1OzRjrNPY9V0jcwYF95F7FUb/Qpg8hm8giOWGosdDBqs=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'SIP List' , "'Uzelac, Adam'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 21:09:11 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Friday, April 03, 2009 1:47 PM > To: Dan Wing; Dean Willis; Jiri Kuthan > Cc: SIP List; Uzelac,Adam > Subject: RE: [Sip] francois' comments and why RFC4474 not > used in the field > > I'm not sure I agree with the logic. > > It seems to me when e2e security of media, then DTS-SRTP (for > UDP) and TLS > (for TCP) makes perfect sense. I agree that (D)TLS is best, and that it protects from all sorts of attacks. > If we allow transcoding, then I don't see the point in e2e > security, since > it obviously is not e2e. I don't understand what ICE gives > you in this case. The public key challange/response, described in draft-wing-sip-identity-media-02, provides better identity assurance than signing IP address and UDP port (as done by RFC4474). Obviously the media is still un-encrypted, though, and encrypted media is better than un-encrypted media. > If we need transcoding, then we might want instead to have a > security mechanism with the transcoder instead. > > For example, we could use DTLS-SRTP where Alice is using the > 4474-like mechanism, > but the transcoder is using it's own cert (instead of a > self-signed one). That > cert's credentials would already be provisioned in Alice's > device. That would > seem like a simple way to do this. Ignoring SRTP for a moment, the complexities involved there are asounding. For example call forwarding and call transfers might need to invoke, or remove, a translator, in a far-removed service provider or enterprise (e.g., forwarding your work calls to your house). -d > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Friday, April 03, 2009 10:44 > > To: Audet, Francois (SC100:3055); 'Dean Willis'; 'Jiri Kuthan' > > Cc: 'SIP List'; 'Uzelac,Adam' > > Subject: RE: [Sip] francois' comments and why RFC4474 not > > used in the field > > > > > > All 5 techniques described in > > > > > > > > > > http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4 > > > > accomplish that using TLS, DTLS-SRTP, ICE, HIP, or ZRTP > -- any of > > > > those choices has different tradeoffs. > > > > > > I'm puzzled by why we would do anything but the DTLS-SRTP > > (and TLS for > > > TCP traffic). > > > > I also prefer TLS. RFC4474 doesn't require TLS, so ICE is in > > the draft to demonstrate it is possible to have identity even > > through a translator and have identity with just RTP (RFC4474 > > provides identity with just RTP). > > > > However, if we used TLS/DTLS-SRTP for identity it would (a) > > break transcoding (as discussed) and (b) require deploying > > SRTP. If doubt we are willing to do > > (a) and (b). > > > > -d > > > > From AUDET@nortel.com Fri Apr 3 14:13:50 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016EB3A63CB for ; Fri, 3 Apr 2009 14:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qitzehyRrUBb for ; Fri, 3 Apr 2009 14:13:49 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E5C5928C179 for ; Fri, 3 Apr 2009 14:13:48 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n33LECV29481; Fri, 3 Apr 2009 21:14:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 16:14:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D3F7F5A@zrc2hxm0.corp.nortel.com> In-Reply-To: <0d0901c9b4a0$8e5fa650$c4f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm0D2BNqKkc1QEORcmKWXlYOHokvwAcWepQAAAPoSAAAI6WwAAAM80gAAbqKoAAAD+XcA== References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> <0d0901c9b4a0$8e5fa650$c4f0200a@cisco.com> From: "Francois Audet" To: "Dan Wing" , "Dean Willis" , "Jiri Kuthan" Cc: SIP List , "Uzelac,Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 21:13:50 -0000 =20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Friday, April 03, 2009 14:10 > To: Audet, Francois (SC100:3055); 'Dean Willis'; 'Jiri Kuthan' > Cc: 'SIP List'; 'Uzelac,Adam' > Subject: RE: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 > The public key challange/response, described in=20 > draft-wing-sip-identity-media-02, provides better identity=20 > assurance than signing IP address and UDP port (as done by=20 > RFC4474). Obviously the media is still un-encrypted, though,=20 > and encrypted media is better than un-encrypted media. I don't understand this. If there is a media transcoder, then what does this identity assurance mean??? The media is not protected. Am I missing something? > > If we need transcoding, then we might want instead to have=20 > a security=20 > > mechanism with the transcoder instead. > > > > For example, we could use DTLS-SRTP where Alice is using=20 > the 4474-like=20 > > mechanism, but the transcoder is using it's own cert (instead of a=20 > > self-signed one). That cert's credentials would already be=20 > provisioned=20 > > in Alice's device. That would seem like a simple way to do this. >=20 > Ignoring SRTP for a moment, the complexities involved there=20 > are asounding. For example call forwarding and call=20 > transfers might need to invoke, or remove, a translator, in a=20 > far-removed service provider or enterprise (e.g., forwarding=20 > your work calls to your house). Well, no, not at all. The model there would be a model where you would HAVE to anchor the media at the service provider (probably the first SBC). The encryption would be between Alice and that. PS: Don't get me wrong, I'm not saying I like this. I a firm = non-believer in all this transcoding stuff. I'd rather have the end-to-end DTLS-SRTP = instead. From dwing@cisco.com Fri Apr 3 14:31:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656883A69AE for ; Fri, 3 Apr 2009 14:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.305 X-Spam-Level: X-Spam-Status: No, score=-6.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sNuhK-Skww4 for ; Fri, 3 Apr 2009 14:31:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4B06E3A68F7 for ; Fri, 3 Apr 2009 14:31:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,321,1235952000"; d="scan'208";a="279871379" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2009 21:32:31 +0000 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 n33LWVJS022267; Fri, 3 Apr 2009 14:32:31 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n33LWVHV017657; Fri, 3 Apr 2009 21:32:31 GMT From: "Dan Wing" To: "'Francois Audet'" , "'Dean Willis'" , "'Jiri Kuthan'" References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> <0d0901c9b4a0$8e5fa650$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7F5A@zrc2hxm0.corp.nortel.com> Date: Fri, 3 Apr 2009 14:32:30 -0700 Message-ID: <0d3101c9b4a3$b1c95340$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D3F7F5A@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm0D2BNqKkc1QEORcmKWXlYOHokvwAcWepQAAAPoSAAAI6WwAAAM80gAAbqKoAAAD+XcAAAQ8cA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3781; t=1238794351; x=1239658351; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=eZYyc0p0Fv8Z0jy3JfviUqiTyOimT4ayVqsUMGJhJBc=; b=K+Sb/wmFFZ3ZkTRhm2YtSfZxFmDRPCdsSQGPwU2uQIfBOj+YWvEvgkxx3D NN+J76Vi5qg1Mu8U2RqEQ1wbl37ueX5VhGpcAsB6CbZyOYqP2WVHIm+Dl/wq i26dE5ekkr; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'SIP List' , "'Uzelac, Adam'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 21:31:29 -0000 > > The public key challange/response, described in > > draft-wing-sip-identity-media-02, provides better identity > > assurance than signing IP address and UDP port (as done by > > RFC4474). Obviously the media is still un-encrypted, though, > > and encrypted media is better than un-encrypted media. > > I don't understand this. If there is a media transcoder, > then what does this identity assurance mean??? The media > is not protected. Am I missing something? RFC4474 doesn't protect the media, either, yet it provides identity. Let's pull the two different attacks apart. There is a difference between them: One attack has someone spoof a "From:", and causes the victim to have a bona-fide conversation with the attacker spoofing the "From:". Protection from that attack is achieved with either RFC4474 (and no SDP modifications between the RFC4474 'authentication service' and 'verifier'), or with the ICE public-key challange described in draft-wing-sip-identity-media. However, you are describing a different attack vector, where an attacker waits for a bona-fide phone call and then sends (and maybe can also also receive) RTP packets with the victim. The victim will believe those received RTP packets are legitimate. To protect from this attack you need to use SRTP. RFC4474 cannot provide protection from this attack unless we assume attackers cannot spoof the source IP address and port of their RTP packets to match the (signed) SDP. We know that attackers can spoof their source IP address. Similarly, the ICE public-key challange described in draft-wing-sip-identity-media does not protect from this attack vector. I look at this as part of a normal evolution of technology. Right now we are in the everybody-trusts-everyone-else camp where P-A-I and From are relatively trustable. This is how email was for about a decade, until that broke down. Then we will need something better for SIP to protect against spoofed From:, but something that is still easily deployed. I suggest that is something *like* the public-key challange described in draft-wing-sip-identity-media. Next, if attackers become more creative and deliver RTP to victims (e.g., "unsolicited advertising") we will need to use SRTP to protect against that sort of attack. > > > If we need transcoding, then we might want instead to have > > a security > > > mechanism with the transcoder instead. > > > > > > For example, we could use DTLS-SRTP where Alice is using > > the 4474-like > > > mechanism, but the transcoder is using it's own cert > (instead of a > > > self-signed one). That cert's credentials would already be > > provisioned > > > in Alice's device. That would seem like a simple way to do this. > > > > Ignoring SRTP for a moment, the complexities involved there > > are asounding. For example call forwarding and call > > transfers might need to invoke, or remove, a translator, in a > > far-removed service provider or enterprise (e.g., forwarding > > your work calls to your house). > > Well, no, not at all. > > The model there would be a model where you would HAVE to anchor the > media at the service provider (probably the first SBC). The encryption > would be between Alice and that. But if some service provider in the middle needs to drop the call to which isn't supported by Alice's SP nor by Bob's SP -- what would that service provider do? Not deploy that spiffy new codec, even though it would save them thousands of dollars a day in satellite bandwidth fees? > PS: Don't get me wrong, I'm not saying I like this. I a firm > non-believer in all this transcoding stuff. I'd rather have the > end-to-end DTLS-SRTP instead. -d From AUDET@nortel.com Fri Apr 3 14:48:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67BF83A6810 for ; Fri, 3 Apr 2009 14:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSvyVAUz517J for ; Fri, 3 Apr 2009 14:48:13 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B5C963A6A2F for ; Fri, 3 Apr 2009 14:47:55 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n33Lmqa08646; Fri, 3 Apr 2009 21:48:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 16:48:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D450582@zrc2hxm0.corp.nortel.com> In-Reply-To: <0d3101c9b4a3$b1c95340$c4f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm0D2BNqKkc1QEORcmKWXlYOHokvwAcWepQAAAPoSAAAI6WwAAAM80gAAbqKoAAAD+XcAAAQ8cAAAD6hrA= References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> <0d0901c9b4a0$8e5fa650$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7F5A@zrc2hxm0.corp.nortel.com> <0d3101c9b4a3$b1c95340$c4f0200a@cisco.com> From: "Francois Audet" To: "Dan Wing" , "Dean Willis" , "Jiri Kuthan" Cc: SIP List , "Uzelac,Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 21:48:14 -0000 =20 > But if some service provider in the middle needs to drop the=20 > call to which isn't supported by Alice's=20 > SP nor by Bob's SP -- what would that service provider do? =20 > Not deploy that spiffy new codec, even though it would save=20 > them thousands of dollars a day in satellite bandwidth fees? Well, no. You just can't do end-to-end media security in this case. I don't understdand at all the claim that if transcoding is=20 allowed, there would be any point in doing media security, or even Secure identity for that matter. I'm just saying if transcoding or media mucking-around is allowed, then just stick with P-AI. From dwing@cisco.com Fri Apr 3 14:55:37 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E95B28C132 for ; Fri, 3 Apr 2009 14:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeAr5HgKE8+v for ; Fri, 3 Apr 2009 14:55:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7063E28C129 for ; Fri, 3 Apr 2009 14:55:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,321,1235952000"; d="scan'208";a="279884430" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2009 21:56:39 +0000 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 n33Lud89023508; Fri, 3 Apr 2009 14:56:39 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n33LudBR004505; Fri, 3 Apr 2009 21:56:39 GMT From: "Dan Wing" To: "'Francois Audet'" , "'Dean Willis'" , "'Jiri Kuthan'" References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> <0d0901c9b4a0$8e5fa650$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7F5A@zrc2hxm0.corp.nortel.com> <0d3101c9b4a3$b1c95340$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D450582@zrc2hxm0.corp.nortel.com> Date: Fri, 3 Apr 2009 14:56:39 -0700 Message-ID: <0d3e01c9b4a7$1110edb0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D450582@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm0D2BNqKkc1QEORcmKWXlYOHokvwAcWepQAAAPoSAAAI6WwAAAM80gAAbqKoAAAD+XcAAAQ8cAAAD6hrAAADpGgA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1925; t=1238795799; x=1239659799; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=AP9nvvYhP7OSxxeAuikF82gMS2/s5d8fx66Cznqbzfk=; b=sn8HWMEL8OrlqMB0iW70lb9cLV8K8nZaXxZ60a5SbCtnatvaUJYIrqKR+T OmaC3vgWMw6hj8ZOKK4/bkFOYfJVUCdr6cv5tYy+n836nw2zmPrGIpnD3mSk zI1rHl/VZJpraLy1ksZ8EgqE6I1jQILpdP0iXsz2lUULxLRgTXcKw=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'SIP List' , "'Uzelac, Adam'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 21:55:37 -0000 > > But if some service provider in the middle needs to drop the > > call to which isn't supported by Alice's > > SP nor by Bob's SP -- what would that service provider do? > > Not deploy that spiffy new codec, even though it would save > > them thousands of dollars a day in satellite bandwidth fees? > > Well, no. You just can't do end-to-end media security in this > case. Ok. Then in that case a way to downgrade to RTP -- which we need in any event -- would be needed. > I don't understdand at all the claim that if transcoding is > allowed, there would be any point in doing media security, or > even Secure identity for that matter. I'm just saying if transcoding > or media mucking-around is allowed, then just stick with P-AI. So that the victim (user2) can distinguish between a service provider doing transcoding for the legimate user1 versus the identity spoofing of user3 (diagram taken from http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03): user3/UA3 | +------+------+ | enterprise3 | +------+------+ | +----------+ +----+-----+ +----------+ +---+ SBC SBC +---+ SBC SBC +---+ SBC SBC +---+ | +----------+ +----------+ +----------+ | | ITSP-A ITSP-B ITSP-C | | | +------+------+ +------+------+ | enterprise1 | | enterprise2 | +------+------+ +------+------+ | | user1/UA1 user2/UA2 -d From rfc-editor@rfc-editor.org Fri Apr 3 16:46:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC6F3A682E; Fri, 3 Apr 2009 16:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.242 X-Spam-Level: X-Spam-Status: No, score=-17.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiOW0z4WewBU; Fri, 3 Apr 2009 16:46:14 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 7822F3A67B4; Fri, 3 Apr 2009 16:46:14 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id CE3A92702AB; Fri, 3 Apr 2009 16:46:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090403234627.CE3A92702AB@bosco.isi.edu> Date: Fri, 3 Apr 2009 16:46:27 -0700 (PDT) Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 5479 on Requirements and Analysis of Media Security Management Protocols X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 23:46:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5479 Title: Requirements and Analysis of Media Security Management Protocols Author: D. Wing, Ed., S. Fries, H. Tschofenig, F. Audet Status: Informational Date: April 2009 Mailbox: dwing@cisco.com, steffen.fries@siemens.com, Hannes.Tschofenig@nsn.com, audet@nortel.com Pages: 45 Characters: 99096 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-media-security-requirements-09.txt URL: http://www.rfc-editor.org/rfc/rfc5479.txt This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. This memo provides information for the Internet community. This document is a product of the Session Initiation Protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From pkyzivat@cisco.com Fri Apr 3 20:44:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C443A6805 for ; Fri, 3 Apr 2009 20:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.575 X-Spam-Level: X-Spam-Status: No, score=-4.575 tagged_above=-999 required=5 tests=[AWL=2.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUo4hIKhVZSq for ; Fri, 3 Apr 2009 20:44:29 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 90F533A67EF for ; Fri, 3 Apr 2009 20:44:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,322,1235952000"; d="scan'208";a="280042444" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2009 03:45:33 +0000 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 n343jXhl024817; Fri, 3 Apr 2009 20:45:33 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n343jWSS023880; Sat, 4 Apr 2009 03:45:32 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 23:45:32 -0400 Received: from [10.86.248.94] ([10.86.248.94]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 23:45:32 -0400 Message-ID: <49D6D7DA.6000002@cisco.com> Date: Fri, 03 Apr 2009 23:45:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dan Wing References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> <0d0901c9b4a0$8e5fa650$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7F5A@zrc2hxm0.corp.nortel.com> <0d3101c9b4a3$b1c95340$c4f0200a@cisco.com> In-Reply-To: <0d3101c9b4a3$b1c95340$c4f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2009 03:45:32.0168 (UTC) FILETIME=[CDDEF880:01C9B4D7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=790; t=1238816733; x=1239680733; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=r7a5Hgxu2q3RuYlF/VdVcqpo5rUtjPYn/nJTNXytNMU=; b=IP0uQvaFloaKjsov5vDqJ8fFqHruuYunol4EGswPCUkz3+TRjitdwnlqK2 5duHx0wY2b3L6NEbN8fRw6i8z1tUK+Qu9Us0HFUi0YUuLcO1zvDHWiMTrqfg p0sbiCy5qfhnNkDGdGBMReceX9qAlXMjF2jsLqtQT5iXpG+WkdwVo=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'SIP List' , 'Francois Audet' , "'Uzelac, Adam'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 03:44:30 -0000 Dan Wing wrote: > But if some service provider in the middle needs to drop the call > to which isn't supported by Alice's SP nor by > Bob's SP -- what would that service provider do? Not deploy that > spiffy new codec, even though it would save them thousands of dollars > a day in satellite bandwidth fees? What does a package delivery service provider do if your package doesn't fit in its shipping containers? Does it hack pieces off the package to make it fit? If it does, do you continue using that service provider? In my world, I want to be told "that is too big for us to accept. If you want us to deliver it for you then you will have to make it smaller." Then I can decide if I want that done or not, and how. Thanks, Paul From pkyzivat@cisco.com Fri Apr 3 20:54:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D24A3A6810 for ; Fri, 3 Apr 2009 20:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.081 X-Spam-Level: X-Spam-Status: No, score=-5.081 tagged_above=-999 required=5 tests=[AWL=1.518, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMFqYNQYK9ow for ; Fri, 3 Apr 2009 20:54:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 22EBC3A680A for ; Fri, 3 Apr 2009 20:54:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,322,1235952000"; d="scan'208";a="280045730" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2009 03:55:45 +0000 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 n343tjNj029868; Fri, 3 Apr 2009 20:55:45 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n343tjYd008738; Sat, 4 Apr 2009 03:55:45 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 23:55:45 -0400 Received: from [10.86.248.94] ([10.86.248.94]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 23:55:44 -0400 Message-ID: <49D6DA3E.5090808@cisco.com> Date: Fri, 03 Apr 2009 23:55:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dan Wing References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> <0d0901c9b4a0$8e5fa650$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7F5A@zrc2hxm0.corp.nortel.com> <0d3101c9b4a3$b1c95340$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D450582@zrc2hxm0.corp.nortel.com> <0d3e01c9b4a7$1110edb0$c4f0200a@cisco.com> In-Reply-To: <0d3e01c9b4a7$1110edb0$c4f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2009 03:55:44.0716 (UTC) FILETIME=[3AFA60C0:01C9B4D9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2940; t=1238817345; x=1239681345; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=EDqrPU6Pw7xxuYATXeZX+OUTfLTovFk2fyBXYAiMynw=; b=HTakHc27tJwUzDHA4PWT5Kf9JY3r+gbphJinm+B5seJJ/gsYzX+wS6eHKJ aNMSPhdvFLCvQ0uZWsD/jliKyXzqu/WsUq1fLOs0ENqZGXqQT5L/2bfoc8Fp e0oe5h7YeIAnywRj1l/bsQHGXgpTg/XOjDM/oq6C0BUodsuCOu0VI=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'SIP List' , 'Francois Audet' , "'Uzelac, Adam'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 03:54:43 -0000 When I am calling you, if I can discover that transcoding is required to establish the call, then I can establish a relationship with a transcoding service that I trust. If I use 3pcc to bring the transcoder into the call, then my call to you is still from *me*, and I vouch for the media source even if it is actually the transcoder. So the transcoding scheme can be as secure (or insecure) as any other. That of course assumes that the means for setting up the secured media session is something that can be set up using 3pcc without my necessarily having to relay the media.) Thanks, Paul Dan Wing wrote: >>> But if some service provider in the middle needs to drop the >>> call to which isn't supported by Alice's >>> SP nor by Bob's SP -- what would that service provider do? >>> Not deploy that spiffy new codec, even though it would save >>> them thousands of dollars a day in satellite bandwidth fees? >> Well, no. You just can't do end-to-end media security in this >> case. > > Ok. Then in that case a way to downgrade to RTP -- which we need > in any event -- would be needed. > >> I don't understdand at all the claim that if transcoding is >> allowed, there would be any point in doing media security, or >> even Secure identity for that matter. I'm just saying if transcoding >> or media mucking-around is allowed, then just stick with P-AI. > > So that the victim (user2) can distinguish between a service provider doing > transcoding for the legimate user1 versus the identity spoofing of user3 > (diagram taken from > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03): > > user3/UA3 > | > +------+------+ > | enterprise3 | > +------+------+ > | > +----------+ +----+-----+ +----------+ > +---+ SBC SBC +---+ SBC SBC +---+ SBC SBC +---+ > | +----------+ +----------+ +----------+ | > | ITSP-A ITSP-B ITSP-C | > | | > +------+------+ +------+------+ > | enterprise1 | | enterprise2 | > +------+------+ +------+------+ > | | > user1/UA1 user2/UA2 > > -d > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From fluffy@cisco.com Sat Apr 4 04:56:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2DD3A6765 for ; Sat, 4 Apr 2009 04:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.625 X-Spam-Level: X-Spam-Status: No, score=-106.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmWiImn2GXbm for ; Sat, 4 Apr 2009 04:56:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C73C43A67AA for ; Sat, 4 Apr 2009 04:56:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,323,1235952000"; d="scan'208";a="280185214" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2009 11:57:46 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n34Bvk0p001465; Sat, 4 Apr 2009 04:57:46 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n34Bvi4J012109; Sat, 4 Apr 2009 11:57:45 GMT From: Cullen Jennings To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D305905@zrc2hxm0.corp.nortel.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <49D17C20.8050907@cisco.com> <042901c9b1b7$5f923a40$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D305905@zrc2hxm0.corp.nortel.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 4 Apr 2009 05:57:44 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3423; t=1238846266; x=1239710266; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=V2xSCjiWQebhDuaZn9/OZyWqfE9ZRwP1caFw+5VoD6I=; b=Gp1qyG0btd6GviY6fQ1H+R7x9zZC0XJmt+ntEnPQ7wr8JXM2/i5glCN9Mt ih+ci9SnI0a8JfSohIoLnGhSAQ04zKSr10u0+sLiJChIP5ABjaMlCIn6WzUV Nfgxhj36RW; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "Uzelac, Adam" , Jon Peterson , SIP IETF , Dan Wing , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 11:56:44 -0000 I can't remember which people thought this did not solve their problem but I remember the characteristics of the discussion were similar of being unclear where this would or would not work and unclear on what the problem was this did not solve. Cullen On Apr 1, 2009, at 10:15 AM, Francois Audet wrote: > So, having re-read all these drafts... > > Cullen/Jon, > > Why is something like draft-wing-sip-identity-media (let's focus just > on the DTLS-SRTP version for now) not a proper solution to the > problem we > are trying to solve? > > The problem being (I think): > Identity Assertion of both the Signalling and the Media, BUT allowing > for relays? > > This has the advantage of being end-to-end. I guess the alternative is > to not have end-to-end media identity assertion, and instead have > Alice-to- > her-service-provider's relay, and Bob-to-his-service-provider's-relay > instead. > >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Monday, March 30, 2009 21:16 >> To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'Jiri Kuthan' >> Cc: 'SIP IETF'; 'Uzelac, Adam'; 'Dean Willis' >> Subject: RE: [Sip] francois' comments and why RFC4474 not >> used in the field >> >> >> >> >>> -----Original Message----- >>> From: Francois Audet [mailto:audet@nortel.com] >>> Sent: Monday, March 30, 2009 7:53 PM >>> To: Jonathan Rosenberg; Jiri Kuthan; Dan WING >>> Cc: SIP IETF; Uzelac, Adam; Dean Willis >>> Subject: Re: [Sip] francois' comments and why RFC4474 not >> used in the >>> field >>> >>> For everybody's reference, can you point to Dan's draft? >> >> It is >> http://tools.ietf.org/html/draft-wing-sip-identity-media-02 >> >> other proposals in the same sphere, >> http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00 >> http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01 >> >> -d >> >> >>> On Mar30 2009 19:12 , "Jonathan Rosenberg" >> wrote: >>> >>>> inline: >>>> >>>> Jiri Kuthan wrote: >>>> >>>> >>>>>> From an end user perspective, I would assert that the >>> most important >>>>>> thing is probably the media. If the callerID says, "this >>> is bob", what >>>>>> is important to the user, is that when I pick up the >>> phone and start >>>>>> talking, it will be Bob who hears me, and Bob that I hear. >>>>>> >>>>>> Consider this litmus test: >>>>>> >>>>>> If the signaling actually came from Mary (perhaps as a >>> third party), >>>>>> but the media goes/comes to/from Bob, who should appear >>> on the caller >>>>>> ID? I say - Bob. >>>>> >>>>> There is a timing aspect in favor of placing identity in >>> signaling -- >>>>> I would like to know whose call is ringing before I answer >>> (if I do). >>>> >>>> You can still have that. Just don't ring the phone until >>> early media has >>>> been exchanged and verified. Indeed if you were doing an >>> ICE-style thing >>>> per Dan's draft, you'd get that for free. >>>> >>>> -Jonathan R. >>>> >>>> >>> >> >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From dwing@cisco.com Sat Apr 4 09:40:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E033A688F for ; Sat, 4 Apr 2009 09:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EFiIEGiPxHX for ; Sat, 4 Apr 2009 09:40:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 88D1B3A688B for ; Sat, 4 Apr 2009 09:40:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,324,1235952000"; d="scan'208";a="280263986" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2009 16:41:09 +0000 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 n34Gf92k020447; Sat, 4 Apr 2009 09:41:09 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n34Gf9m1019455; Sat, 4 Apr 2009 16:41:09 GMT From: "Dan Wing" To: "'Paul Kyzivat'" References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> <0d0901c9b4a0$8e5fa650$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7F5A@zrc2hxm0.corp.nortel.com> <0d3101c9b4a3$b1c95340$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D450582@zrc2hxm0.corp.nortel.com> <0d3e01c9b4a7$1110edb0$c4f0200a@cisco.com> <49D6DA3E.5090808@cisco.com> Date: Sat, 4 Apr 2009 09:41:08 -0700 Message-ID: <0e5001c9b544$27dda310$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49D6DA3E.5090808@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm02Tu+Ak2FjZmIQ2a2nMa1NOwsLQAauYKg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3454; t=1238863269; x=1239727269; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=eQqhJHJ7HRjA++W87FXLU6Tre/EwooS1cKpu/YSaDQA=; b=fEqvd2DQFXL7HQ61VqZ7qB/eR7h9979GXIhWe/6osNgMjj/E5O2hlq4t5r 6GmrWAWq0zZW/BGq/Az/ibxaKpgZdPirkuST+oJhDcGpHP5wwRnACHGfSNNH fjH4v4Bxsh7GFMIqDKmyqkQKKGkZGnzcrJ3WkaPxEf+76v1sqDMYM=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'SIP List' , 'Francois Audet' , "'Uzelac, Adam'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 16:40:06 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, April 03, 2009 8:56 PM > To: Dan Wing > Cc: 'Francois Audet'; 'Dean Willis'; 'Jiri Kuthan'; 'SIP > List'; 'Uzelac, Adam' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > When I am calling you, if I can discover that transcoding is > required to establish the call, How would you do that? -d > then I can establish a relationship with a > transcoding service that I trust. If I use 3pcc to bring the > transcoder > into the call, then my call to you is still from *me*, and I > vouch for > the media source even if it is actually the transcoder. So the > transcoding scheme can be as secure (or insecure) as any > other. That of > course assumes that the means for setting up the secured > media session > is something that can be set up using 3pcc without my > necessarily having > to relay the media.) > > Thanks, > Paul > > Dan Wing wrote: > >>> But if some service provider in the middle needs to drop the > >>> call to which isn't supported by Alice's > >>> SP nor by Bob's SP -- what would that service provider do? > >>> Not deploy that spiffy new codec, even though it would save > >>> them thousands of dollars a day in satellite bandwidth fees? > >> Well, no. You just can't do end-to-end media security in this > >> case. > > > > Ok. Then in that case a way to downgrade to RTP -- which we need > > in any event -- would be needed. > > > >> I don't understdand at all the claim that if transcoding is > >> allowed, there would be any point in doing media security, or > >> even Secure identity for that matter. I'm just saying if > transcoding > >> or media mucking-around is allowed, then just stick with P-AI. > > > > So that the victim (user2) can distinguish between a > service provider doing > > transcoding for the legimate user1 versus the identity > spoofing of user3 > > (diagram taken from > > > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-impor > tant-03): > > > > user3/UA3 > > | > > +------+------+ > > | enterprise3 | > > +------+------+ > > | > > +----------+ +----+-----+ +----------+ > > +---+ SBC SBC +---+ SBC SBC +---+ SBC SBC +---+ > > | +----------+ +----------+ +----------+ | > > | ITSP-A ITSP-B ITSP-C | > > | | > > +------+------+ +------+------+ > > | enterprise1 | | enterprise2 | > > +------+------+ +------+------+ > > | | > > user1/UA1 user2/UA2 > > > > -d > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > From pkyzivat@cisco.com Sat Apr 4 13:59:17 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5503A6980 for ; Sat, 4 Apr 2009 13:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=0.996, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiArpP2POpgU for ; Sat, 4 Apr 2009 13:59:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C97613A68D8 for ; Sat, 4 Apr 2009 13:59:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,324,1235952000"; d="scan'208";a="150338673" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2009 21:00:08 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n34L08YX006474; Sat, 4 Apr 2009 17:00:08 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n34L08UR007156; Sat, 4 Apr 2009 21:00:08 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Apr 2009 17:00:08 -0400 Received: from [10.86.248.94] ([10.86.248.94]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Apr 2009 17:00:07 -0400 Message-ID: <49D7CA56.5050207@cisco.com> Date: Sat, 04 Apr 2009 17:00:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dan Wing References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> <0d0901c9b4a0$8e5fa650$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7F5A@zrc2hxm0.corp.nortel.com> <0d3101c9b4a3$b1c95340$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D450582@zrc2hxm0.corp.nortel.com> <0d3e01c9b4a7$1110edb0$c4f0200a@cisco.com> <49D6DA3E.5090808@cisco.com> <0e5001c9b544$27dda310$c4f0200a@cisco.com> In-Reply-To: <0e5001c9b544$27dda310$c4f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2009 21:00:07.0676 (UTC) FILETIME=[55C1CBC0:01C9B568] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4403; t=1238878808; x=1239742808; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20 |To:=20Dan=20Wing=20; bh=tJ1JL/X8D/p8sNDzePAi61RX25xYj4C9ZUPQLChtrrw=; b=QKTTzoMtT8w+8PiQ2xHYPeM3LUz6q5DFG2r5Stc3lMY0k2W6t9Ir9FgFMS V1ktfbu+ocLaRr42f8RqWVbbIz5M//V+K8D74BwmCEuwoiAF11w+QBCfWmAa /3twuJrWNq; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 'SIP List' , 'Francois Audet' , "'Uzelac, Adam'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 20:59:17 -0000 Dan Wing wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, April 03, 2009 8:56 PM >> To: Dan Wing >> Cc: 'Francois Audet'; 'Dean Willis'; 'Jiri Kuthan'; 'SIP >> List'; 'Uzelac, Adam' >> Subject: Re: [Sip] francois' comments and why RFC4474 not >> used in the field >> >> When I am calling you, if I can discover that transcoding is >> required to establish the call, > > How would you do that? There are a number of possibilities: 1) I could send an offerless invite, and await an offer from you. Then if it isn't something I can do myself I can recruit a transcoder to help. 2) I could send an invite with offer, and the callee could recruit the transcoder if needed. 3) I can send an invite with offer, and if you can't handle it, and don't have a transcoding alternative, you could send a 18x with an answer that refuses the media stream, but mentions the codecs you do support. 4) like 3, but use the sdp capability stuff to express the codecs that are supported in each direction. 5) I send invite with offer, you reject it with 488 because you can't support the codecs offered. The 488 indicates the codecs you do support. Then I recruit a transcoder and try the call again, offering somthing I expect you will be able to support. Thanks, Paul > -d > > >> then I can establish a relationship with a >> transcoding service that I trust. If I use 3pcc to bring the >> transcoder >> into the call, then my call to you is still from *me*, and I >> vouch for >> the media source even if it is actually the transcoder. So the >> transcoding scheme can be as secure (or insecure) as any >> other. That of >> course assumes that the means for setting up the secured >> media session >> is something that can be set up using 3pcc without my >> necessarily having >> to relay the media.) >> >> Thanks, >> Paul >> >> Dan Wing wrote: >>>>> But if some service provider in the middle needs to drop the >>>>> call to which isn't supported by Alice's >>>>> SP nor by Bob's SP -- what would that service provider do? >>>>> Not deploy that spiffy new codec, even though it would save >>>>> them thousands of dollars a day in satellite bandwidth fees? >>>> Well, no. You just can't do end-to-end media security in this >>>> case. >>> Ok. Then in that case a way to downgrade to RTP -- which we need >>> in any event -- would be needed. >>> >>>> I don't understdand at all the claim that if transcoding is >>>> allowed, there would be any point in doing media security, or >>>> even Secure identity for that matter. I'm just saying if >> transcoding >>>> or media mucking-around is allowed, then just stick with P-AI. >>> So that the victim (user2) can distinguish between a >> service provider doing >>> transcoding for the legimate user1 versus the identity >> spoofing of user3 >>> (diagram taken from >>> >> http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-impor >> tant-03): >>> user3/UA3 >>> | >>> +------+------+ >>> | enterprise3 | >>> +------+------+ >>> | >>> +----------+ +----+-----+ +----------+ >>> +---+ SBC SBC +---+ SBC SBC +---+ SBC SBC +---+ >>> | +----------+ +----------+ +----------+ | >>> | ITSP-A ITSP-B ITSP-C | >>> | | >>> +------+------+ +------+------+ >>> | enterprise1 | | enterprise2 | >>> +------+------+ +------+------+ >>> | | >>> user1/UA1 user2/UA2 >>> >>> -d >>> >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > > From dwing@cisco.com Sat Apr 4 17:22:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BFD33A6A81 for ; Sat, 4 Apr 2009 17:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.323 X-Spam-Level: X-Spam-Status: No, score=-6.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPJt9Laq5B0t for ; Sat, 4 Apr 2009 17:22:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AEB8F3A6A5C for ; Sat, 4 Apr 2009 17:22:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,325,1235952000"; d="scan'208";a="280392194" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2009 00:23:52 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n350Nqf3005529; Sat, 4 Apr 2009 17:23:52 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n350Np8i024924; Sun, 5 Apr 2009 00:23:51 GMT From: "Dan Wing" To: "'Cullen Jennings'" , "'Francois Audet'" References: <49D17C20.8050907@cisco.com> <042901c9b1b7$5f923a40$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D305905@zrc2hxm0.corp.nortel.com> Date: Sat, 4 Apr 2009 17:23:51 -0700 Message-ID: <0e9501c9b584$cbf8cac0$c4f0200a@cisco.com> 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: Acm1HJFoHYXMGmVtRUObslMYSXAPwAAZbtww DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10490; t=1238891032; x=1239755032; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=6Jts8s/HacrJNM5y6oLU15vg7L8/MOTkxIsoN0Fdqfs=; b=FxJa/atgwca1VYZN9kwYZRI/C7J7J5lOSDC2nvtY9CD9LQO8109+KdzZ+U Kn3On1y4C/bEiLcCKM25gcBMSnBfe5NjJZrCL44QeSbyYH49tmoIZtrhhyH3 nCU288+Ef6mkeoWbiUwIfTQwMqCsKt30AEfsFQxg8fE0056SNhadM=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "'Uzelac, Adam'" , 'Jon Peterson' , 'SIP IETF' , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 00:22:49 -0000 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Saturday, April 04, 2009 4:58 AM > To: Francois Audet > Cc: Dan Wing; Jonathan Rosenberg; Jiri Kuthan; Jon Peterson; > SIP IETF; Uzelac, Adam; Dean Willis > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > I can't remember which people thought this did not solve > their problem > but I remember the characteristics of the discussion were similar of > being unclear where this would or would not work and unclear on what > the problem was this did not solve. > > Cullen Here are the minutes regarding draft-wing-sip-identity-media, identity problem, and identity requirements from the last 6 consecutive IETF meetings: Minutes from SIP meeting at IETF69, Chicago, July 22-27, 2007, http://www.ietf.org/proceedings/07jul/minutes/sip.html Media Identity Led by Dan Wing. Slides presented. Dan Wing reports that Cisco has made IPR claims related to this material. Discussion centered on difficulties with applying RFC 4474 techniques through session border controllers and other B2BUA. Some participants in the discussion questioned the use case or wondered whether the problem posed by the use case needs to be solved. Conclusion: There was no consensus to pursue the work at this time, but the WG might be willing to reconsider if more convincing use cases can be provided. Minutes from SIP meeting at IETF70, Vancouver, December 2-7, 2007, http://www.ietf.org/proceedings/07dec/minutes/sip.txt Topic: Media Identity led by Dan Wing Slides presented and included in proceedings Issue: SBCs break 4474 because SDP signed by Identity is rewritten by SBC Francois observed that this problem may only occur when it is an SBC outside the domain of the Identity server that is doing the rewriting. Hannes suggested extending IDENTITY to be like DKIM, which can selectively sign pieces. General discussion revealed that most of the material in the signaling is problematic from a signature perspective. IP Addresses are essentially meaningless, especially across domain boundaries. Phone numbers are little better, with end-nodes having no real way to test assertions about them (and perhaps a service provided signature is the best we can do here). RFC 4474 already documents limitations with respect to telephone numbers. There seems to be an emerging thread of consensus here that what we need is some way to bind media to signaling -- that is, to by inspection of the media and the signaling be able to say with some level of certainty that they are related -- and specifically, to say "this media is a result of that signaling". Chairs noted that there is additional work required her to be able to frame this into the sort of requirement that could be added to a charter. Minutes from SIP meeting at IETF71, Philadelphia, March 9-14, 2008, https://www3.ietf.org/proceedings/08mar/minutes/sip.txt Topic: SIP-Identity Issues by John Elwell Slides presented Issue: E.164 and RFC 4474 and DTLS-SRTP We have known issues with RFC 4474 handling of phone numbers, especially given the inconsistent processing of phone numbers and mixed URI encoding methods. The critical manifestation here is that if RFC 4474 is used to assert an identity derived from the PSTN (specifically, through a gateway via Caller-ID services) then there may be no basis to trust that assertion. This is problematic in that DTLS-SRTP requires and RFC 4474 Identity header to provide the fingerprint that correlates media with signaling. We would like to be able to use DTLS-SRTP with calls to/from PSTN gateways. However, this could result in teh insertion of misleading Identity headers. Discussion focused on defining the problem and the three "problem" use cases. There was a conclusion that this is definitely a problem that needs to be fixed. There seems to be a possibility that it could be fixed by guidance in the DTLS-SRTP framework, which we would like to conclude as soon as possible. However, there is at this time no consensus on a solution. For the record, an extended conversation took off on the mailing list following the in-meeting discussion, and that conversation has brought forward at least one proposal (a From: header URI parameter that would be inserted by gateways) that might meet the requirements. Issue: Impact of SBCs on RFC 4474 and SRTP-DTLS SBCs may make changes to requests that alter the RFC 4474 Identity header in such a way that it can not meet the requirements of SRTP-DTLS. Several fixes have been proposed and were discussed briefly. Further discussion is required. Minutes from SIP meeting at IETF72, Dublin, July 27 - August 1, 2008, http://www.ietf.org/proceedings/08jul/minutes/sip.txt Topic: Identity Issues Led by John Elwell Slides presented and included in proceedings John discussed the problem background and discussed a significant use case involving SBCs that perform media steering, with which RFC 4474 may not be effectively used. Discussion followed as to whether this "failure" is actually a feature and design goal of RFC 4474, with no consensus developing. This discussion included a lengthy review of the rationale of RFC 4474 by Jon Peterson. Further use cases, such as preservation of identity across multiple service provider SBC boundaries, were raised. Discussion on what to do next continued without final conclusions. Minutes from SIP meeting, IETF 73, November 16-21, 2008, http://www.ietf.org/proceedings/08nov/index.html Topic: Path forward on Identity Issues Led by Jon Peterson Slides Presented No draft Issue: Desirable Properties Desirable properties: - Generality ? one universal mechanism is a good thing. - Avoids bid-downs. - Authentication - enables media security - useful to decide whether or not to accept a request Hadriel noted that these are all good, but we can't have them. What are we willing to settle for tha twe can actually deliver? Several others voiced similar positions on the "noble but futile" theme. Issue: Configurability Proposed that some level of flexibility on what headers get signed might be acceptable. Hadriel suggested that we come up with a set of rules that intermediaries could comply with. Sam Hartman suggested that we further need a compromise about what we need to sign to get secure media that shows up as secure on the other end, with a spec that provides it. If we can't get it in this working group, we may need work that spans the entire IETF to get it. Further discussion ensued. No conclusions were noted. And Hadriel did a presentation at IETF74 but minutes haven't yet been posted. -d > > On Apr 1, 2009, at 10:15 AM, Francois Audet wrote: > > > So, having re-read all these drafts... > > > > Cullen/Jon, > > > > Why is something like draft-wing-sip-identity-media (let's > focus just > > on the DTLS-SRTP version for now) not a proper solution to the > > problem we > > are trying to solve? > > > > The problem being (I think): > > Identity Assertion of both the Signalling and the > Media, BUT allowing > > for relays? > > > > This has the advantage of being end-to-end. I guess the > alternative is > > to not have end-to-end media identity assertion, and instead have > > Alice-to- > > her-service-provider's relay, and > Bob-to-his-service-provider's-relay > > instead. > > > >> -----Original Message----- > >> From: Dan Wing [mailto:dwing@cisco.com] > >> Sent: Monday, March 30, 2009 21:16 > >> To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; > 'Jiri Kuthan' > >> Cc: 'SIP IETF'; 'Uzelac, Adam'; 'Dean Willis' > >> Subject: RE: [Sip] francois' comments and why RFC4474 not > >> used in the field > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Francois Audet [mailto:audet@nortel.com] > >>> Sent: Monday, March 30, 2009 7:53 PM > >>> To: Jonathan Rosenberg; Jiri Kuthan; Dan WING > >>> Cc: SIP IETF; Uzelac, Adam; Dean Willis > >>> Subject: Re: [Sip] francois' comments and why RFC4474 not > >> used in the > >>> field > >>> > >>> For everybody's reference, can you point to Dan's draft? > >> > >> It is > >> http://tools.ietf.org/html/draft-wing-sip-identity-media-02 > >> > >> other proposals in the same sphere, > >> http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00 > >> http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01 > >> > >> -d > >> > >> > >>> On Mar30 2009 19:12 , "Jonathan Rosenberg" > >> wrote: > >>> > >>>> inline: > >>>> > >>>> Jiri Kuthan wrote: > >>>> > >>>> > >>>>>> From an end user perspective, I would assert that the > >>> most important > >>>>>> thing is probably the media. If the callerID says, "this > >>> is bob", what > >>>>>> is important to the user, is that when I pick up the > >>> phone and start > >>>>>> talking, it will be Bob who hears me, and Bob that I hear. > >>>>>> > >>>>>> Consider this litmus test: > >>>>>> > >>>>>> If the signaling actually came from Mary (perhaps as a > >>> third party), > >>>>>> but the media goes/comes to/from Bob, who should appear > >>> on the caller > >>>>>> ID? I say - Bob. > >>>>> > >>>>> There is a timing aspect in favor of placing identity in > >>> signaling -- > >>>>> I would like to know whose call is ringing before I answer > >>> (if I do). > >>>> > >>>> You can still have that. Just don't ring the phone until > >>> early media has > >>>> been exchanged and verified. Indeed if you were doing an > >>> ICE-style thing > >>>> per Dan's draft, you'd get that for free. > >>>> > >>>> -Jonathan R. > >>>> > >>>> > >>> > >> > >> > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > From dwing@cisco.com Sun Apr 5 08:15:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1A13A68C9 for ; Sun, 5 Apr 2009 08:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.326 X-Spam-Level: X-Spam-Status: No, score=-6.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 081EjFK-p7TL for ; Sun, 5 Apr 2009 08:15:53 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9D2A53A6B28 for ; Sun, 5 Apr 2009 08:15:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,326,1235952000"; d="scan'208";a="70411777" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 05 Apr 2009 15:16:57 +0000 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 n35FGvUs003514; Sun, 5 Apr 2009 08:16:57 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n35FGuVn012266; Sun, 5 Apr 2009 15:16:57 GMT From: "Dan Wing" To: "'Paul Kyzivat'" References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> <0c1201c9b483$d45b04a0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7EB6@zrc2hxm0.corp.nortel.com> <0d0901c9b4a0$8e5fa650$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F7F5A@zrc2hxm0.corp.nortel.com> <0d3101c9b4a3$b1c95340$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D450582@zrc2hxm0.corp.nortel.com> <0d3e01c9b4a7$1110edb0$c4f0200a@cisco.com> <49D6DA3E.5090808@cisco.com> <0e5001c9b544$27dda310$c4f0200a@cisco.com> <4 9D7CA56.5050207@cisc o.com> Date: Sun, 5 Apr 2009 08:16:55 -0700 Message-ID: <0ed701c9b601$8e7a44d0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49D7CA56.5050207@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm1aFXzyymNqZLNQpm9ef7YdIyFHAAmO6/A DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5325; t=1238944617; x=1239808617; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=qwojVur6eQf4q1eirN76N7gybiiO8StZO2cOoIc1ANs=; b=KDNvLjRQzx6KzKVSbwQ8Onk00RqKdhUbNqzDW8qu50huDIqNkgvuZHAlwS uRSQXnC2zy0YFp1I8UHd2J5k0Ti86ZSAW/wL9eDL2WQURKjdSOpyQRM5vbQJ ktwaRGEgy+; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'SIP List' , 'Francois Audet' , "'Uzelac, Adam'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 15:15:54 -0000 Setting up SRTP-only calls and using one or all of those techniques would certainly be a way to learn how often intermediate transcoders are needed and cannot be invoked. Someone should try those techniques against some SIP peers. I suspect even more interoperability issues would be encountered, but I am only guessing. -d > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Saturday, April 04, 2009 2:00 PM > To: Dan Wing > Cc: 'Francois Audet'; 'Dean Willis'; 'Jiri Kuthan'; 'SIP > List'; 'Uzelac, Adam' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > > Dan Wing wrote: > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, April 03, 2009 8:56 PM > >> To: Dan Wing > >> Cc: 'Francois Audet'; 'Dean Willis'; 'Jiri Kuthan'; 'SIP > >> List'; 'Uzelac, Adam' > >> Subject: Re: [Sip] francois' comments and why RFC4474 not > >> used in the field > >> > >> When I am calling you, if I can discover that transcoding is > >> required to establish the call, > > > > How would you do that? > > There are a number of possibilities: > > 1) I could send an offerless invite, and await an offer from > you. Then > if it isn't something I can do myself I can recruit a > transcoder to help. > > 2) I could send an invite with offer, and the callee could > recruit the > transcoder if needed. > > 3) I can send an invite with offer, and if you can't handle it, and > don't have a transcoding alternative, you could send a 18x with an > answer that refuses the media stream, but mentions the codecs you do > support. > > 4) like 3, but use the sdp capability stuff to express the > codecs that > are supported in each direction. > > 5) I send invite with offer, you reject it with 488 because you can't > support the codecs offered. The 488 indicates the codecs you > do support. > Then I recruit a transcoder and try the call again, offering > somthing I > expect you will be able to support. > > Thanks, > Paul > > > -d > > > > > >> then I can establish a relationship with a > >> transcoding service that I trust. If I use 3pcc to bring the > >> transcoder > >> into the call, then my call to you is still from *me*, and I > >> vouch for > >> the media source even if it is actually the transcoder. So the > >> transcoding scheme can be as secure (or insecure) as any > >> other. That of > >> course assumes that the means for setting up the secured > >> media session > >> is something that can be set up using 3pcc without my > >> necessarily having > >> to relay the media.) > >> > >> Thanks, > >> Paul > >> > >> Dan Wing wrote: > >>>>> But if some service provider in the middle needs to drop the > >>>>> call to which isn't supported by Alice's > >>>>> SP nor by Bob's SP -- what would that service provider do? > >>>>> Not deploy that spiffy new codec, even though it would save > >>>>> them thousands of dollars a day in satellite bandwidth fees? > >>>> Well, no. You just can't do end-to-end media security in this > >>>> case. > >>> Ok. Then in that case a way to downgrade to RTP -- which we need > >>> in any event -- would be needed. > >>> > >>>> I don't understdand at all the claim that if transcoding is > >>>> allowed, there would be any point in doing media security, or > >>>> even Secure identity for that matter. I'm just saying if > >> transcoding > >>>> or media mucking-around is allowed, then just stick with P-AI. > >>> So that the victim (user2) can distinguish between a > >> service provider doing > >>> transcoding for the legimate user1 versus the identity > >> spoofing of user3 > >>> (diagram taken from > >>> > >> http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-impor > >> tant-03): > >>> user3/UA3 > >>> | > >>> +------+------+ > >>> | enterprise3 | > >>> +------+------+ > >>> | > >>> +----------+ +----+-----+ +----------+ > >>> +---+ SBC SBC +---+ SBC SBC +---+ SBC SBC +---+ > >>> | +----------+ +----------+ +----------+ | > >>> | ITSP-A ITSP-B ITSP-C | > >>> | | > >>> +------+------+ > +------+------+ > >>> | enterprise1 | | > enterprise2 | > >>> +------+------+ > +------+------+ > >>> | | > >>> user1/UA1 user2/UA2 > >>> > >>> -d > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the > application of sip > >>> > > > > From john-ietf@jck.com Thu Apr 2 18:45:56 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E2B3A6D29; Thu, 2 Apr 2009 18:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 CVqvHhQk76rt; Thu, 2 Apr 2009 18:45:55 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 818383A6C2A; Thu, 2 Apr 2009 18:45:55 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1LpYUf-000N6E-Qw; Thu, 02 Apr 2009 21:46:54 -0400 Date: Thu, 02 Apr 2009 21:46:53 -0400 From: John C Klensin To: Keith Moore , Paul Kyzivat Message-ID: <3144A139F1F4B00535C2A8F4@PST.JCK.COM> In-Reply-To: <49D54E3A.4080702@cs.utk.edu> References: <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> <49D4461E.2050709@cs.utk.edu> <49D54893.6010008@cisco.com> <49D54E3A.4080702@cs.utk.edu> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 06 Apr 2009 05:19:36 -0700 Cc: SIP@ietf.org, apps-discuss@ietf.org Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:45:56 -0000 --On Thursday, April 02, 2009 19:46 -0400 Keith Moore wrote: > not clear. IMHO, trying to specify every aspect of detail of > a protocol syntax using a formal specification language can be > misleading and cause more interop failures, than a looser > specification written in ABNF plus some exceptions in the > text. One reason for the additional failures when using the > precise formal specification is that you don't really benefit > from that specification unless you feed it to a program that > will automatically generate the recognizer. And if you do > automatically generate a recognizer from the formal > specification, you often find that it doesn't report errors in > the way that you'd like, doesn't perform as well as you want, > etc. Yes. And if the protocol is even nearly as complicated as SIP, you need a formal language that can specify semantics as well as syntax to get even close to a full description of the protocol. Syntax alone just doesn't do it. I would slightly disagree with Keith's characterization because those things can be good for generating reference implementations that can be checked against production ones to see if the latter are working correctly. But I agree that such a reference implementation isn't likely to be something one would like to use in production for the reasons he gives. I could suggest a few specification languages of that variety from experience (and there are more in the literature), but, as you point out... >> But there is a big tradeoff there. At least many people are >> capable of reading ABNF, and a reasonable number of those can >> accurately understand what it means. A somewhat smaller, but >> still significant, number can write it correctly. Its >> important that the people involved in the standardization >> process, and that implement the standard, be able to >> understand it. A more powerful specification language, that >> fewer people could understand, might not be such a great >> choice. >... the languages that can be used to specify not just static syntax but semantics and actions require serious work to understand how to read and even more to be able to write, leading to only a small population who can really understand such a specification. That is usually considered bad news although I've been in situations in which it is considered job security. > The trick is to design the protocol in such a way that a > precise formal syntax specification is not necessary. This > implies having a certain degree of simplicity and regularity > in the protocol. Unfortunately, SIP probably fails the test that implies. And no alternate choice of specification method is going to change that. john From AUDET@nortel.com Mon Apr 6 09:03:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B103A698B for ; Mon, 6 Apr 2009 09:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8BdgBm5skkv for ; Mon, 6 Apr 2009 09:03:40 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C621A3A6975 for ; Mon, 6 Apr 2009 09:03:39 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n36G44B12518; Mon, 6 Apr 2009 16:04:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Apr 2009 11:04:31 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D451069@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm1HJoIVkOU/uvMRX60tnISZ1VVEwBtKocw References: <49D17C20.8050907@cisco.com> <042901c9b1b7$5f923a40$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D305905@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Cullen Jennings" Cc: "Uzelac, Adam" , Jon Peterson , SIP IETF , Dan Wing , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 16:03:41 -0000 Right, So now that we have progressed, let's try to figure out what the = problems with this approach are (if any). =20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Saturday, April 04, 2009 04:58 > To: Audet, Francois (SC100:3055) > Cc: Dan Wing; Jonathan Rosenberg; Jiri Kuthan; Jon Peterson;=20 > SIP IETF; Uzelac, Adam; Dean Willis > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > I can't remember which people thought this did not solve=20 > their problem but I remember the characteristics of the=20 > discussion were similar of being unclear where this would or=20 > would not work and unclear on what the problem was this did not solve. >=20 > Cullen >=20 > On Apr 1, 2009, at 10:15 AM, Francois Audet wrote: >=20 > > So, having re-read all these drafts... > > > > Cullen/Jon, > > > > Why is something like draft-wing-sip-identity-media (let's=20 > focus just=20 > > on the DTLS-SRTP version for now) not a proper solution to=20 > the problem=20 > > we are trying to solve? > > > > The problem being (I think): > > Identity Assertion of both the Signalling and the=20 > Media, BUT allowing > > for relays? > > > > This has the advantage of being end-to-end. I guess the=20 > alternative is=20 > > to not have end-to-end media identity assertion, and instead have > > Alice-to- > > her-service-provider's relay, and=20 > Bob-to-his-service-provider's-relay > > instead. > > > >> -----Original Message----- > >> From: Dan Wing [mailto:dwing@cisco.com] > >> Sent: Monday, March 30, 2009 21:16 > >> To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg';=20 > 'Jiri Kuthan' > >> Cc: 'SIP IETF'; 'Uzelac, Adam'; 'Dean Willis' > >> Subject: RE: [Sip] francois' comments and why RFC4474 not=20 > used in the=20 > >> field > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Francois Audet [mailto:audet@nortel.com] > >>> Sent: Monday, March 30, 2009 7:53 PM > >>> To: Jonathan Rosenberg; Jiri Kuthan; Dan WING > >>> Cc: SIP IETF; Uzelac, Adam; Dean Willis > >>> Subject: Re: [Sip] francois' comments and why RFC4474 not > >> used in the > >>> field > >>> > >>> For everybody's reference, can you point to Dan's draft? > >> > >> It is > >> http://tools.ietf.org/html/draft-wing-sip-identity-media-02 > >> > >> other proposals in the same sphere, > >> http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00 > >> http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01 > >> > >> -d > >> > >> > >>> On Mar30 2009 19:12 , "Jonathan Rosenberg" > >> wrote: > >>> > >>>> inline: > >>>> > >>>> Jiri Kuthan wrote: > >>>> > >>>> > >>>>>> From an end user perspective, I would assert that the > >>> most important > >>>>>> thing is probably the media. If the callerID says, "this > >>> is bob", what > >>>>>> is important to the user, is that when I pick up the > >>> phone and start > >>>>>> talking, it will be Bob who hears me, and Bob that I hear. > >>>>>> > >>>>>> Consider this litmus test: > >>>>>> > >>>>>> If the signaling actually came from Mary (perhaps as a > >>> third party), > >>>>>> but the media goes/comes to/from Bob, who should appear > >>> on the caller > >>>>>> ID? I say - Bob. > >>>>> > >>>>> There is a timing aspect in favor of placing identity in > >>> signaling -- > >>>>> I would like to know whose call is ringing before I answer > >>> (if I do). > >>>> > >>>> You can still have that. Just don't ring the phone until > >>> early media has > >>>> been exchanged and verified. Indeed if you were doing an > >>> ICE-style thing > >>>> per Dan's draft, you'd get that for free. > >>>> > >>>> -Jonathan R. > >>>> > >>>> > >>> > >> > >> > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 From dean.willis@softarmor.com Mon Apr 6 21:34:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A872A3A6822 for ; Mon, 6 Apr 2009 21:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 r3LF7jY6k8ga for ; Mon, 6 Apr 2009 21:34:19 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C5A643A67E9 for ; Mon, 6 Apr 2009 21:34:19 -0700 (PDT) Received: from [192.168.2.103] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n374ZJLG010746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2009 23:35:22 -0500 Message-Id: <408BC805-1D7D-42C6-A3E7-FA949A3FAD13@softarmor.com> From: Dean Willis To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D3F77C5@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 23:35:13 -0500 References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> <731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D3B4070@zrc2hxm0.corp.nortel.com> <420E8A49-A414-49AB-A5E3-25B3EC5D3A33@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D3F77C5@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.930.3) Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 04:34:20 -0000 On Apr 3, 2009, at 11:22 AM, Francois Audet wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Thursday, April 02, 2009 21:02 >> To: Audet, Francois (SC100:3055) >> Cc: Dwight, Timothy M (Tim); Cullen Jennings; sip@ietf.org; >> DRAGE, Keith (Keith) >> Subject: Re: [Sip] francois' comments and why RFC4474 not >> used in the field >> >>> And what draft-wing-sip-identity-media does is show how and >> 4474-like >>> mechanism that doesn't protect the IP address can be used in >>> conjunction with DTLS-SRTP, to provide an adequate level of >> security. >>> >>> So, I'll repeat the question from a previous email: what's >> wrong with >>> draft-wing-sip-identity-media??? >> >> If I understand the argument, extending the d-w-s-i-m >> approach to non- DTLS media legitimizes the obfuscation of >> the one media identifier we do have -- the IP address. Some >> people seem to find this unacceptable. > > No, that's not what I'm saying. > > I'm saying draft-wing-sip-identity-media WITH DTLS-SRTP. > ^^^^ > > What's wrong with that approach? > > Unless I'm missing something, it does seem to achieve end-to-end > media and identity security. Yes, but it does so at the expense of weakening RFC 4474 when it is used without DTLS. I believe Jon has said that he wishes to be able to use signaling identity without DTLS and considers the presentation of IP addresses in the identity signature to be essential. Since you want to change RFC 4474 to allow MITM editing of IP address information (thereby weakening RFC 4474 protections in Jon's scenario), he doesn't like your idea, -- Dean From AUDET@nortel.com Mon Apr 6 21:54:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4699A3A6810 for ; Mon, 6 Apr 2009 21:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.385 X-Spam-Level: X-Spam-Status: No, score=-5.385 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1S2pXGAhYRx for ; Mon, 6 Apr 2009 21:54:27 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 558193A680A for ; Mon, 6 Apr 2009 21:54:27 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n374sqX28691; Tue, 7 Apr 2009 04:54:52 GMT Received: from 47.103.119.44 ([47.103.119.44]) by zrc2hxm0.corp.nortel.com ([47.103.119.44]) with Microsoft Exchange Server HTTP-DAV ; Tue, 7 Apr 2009 04:54:40 +0000 References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D001B51C00@GBNTHT12009MSX.gb002.siemens.net> <32590116-67B7-4C23-8159-7991372972EF@softarmor.com> <731CAEBE-4768-4AB5-975F-A038F9360CEA@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D3B4070@zrc2hxm0.corp.nortel.com> <420E8A49-A414-49AB-A5E3-25B3EC5D3A33@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D3F77C5@zrc2hxm0.corp.nortel.com> <408BC805-1D7D-42C6-A3E7-FA949A3FAD13@softarmor.com> Message-ID: From: "Francois Audet" To: "Dean Willis" thread-topic: [Sip] francois' comments and why RFC4474 not used in the field thread-index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fA== In-Reply-To: <408BC805-1D7D-42C6-A3E7-FA949A3FAD13@softarmor.com> Content-Type: text/plain; format=flowed; delsp=yes; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (iPod Mail 5H11a) Date: Mon, 6 Apr 2009 21:54:39 -0700 Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 04:54:28 -0000 > > Yes, but it does so at the expense of weakening RFC 4474 when it is > used without DTLS. > > I believe Jon has said that he wishes to be able to use signaling > identity without DTLS and considers the presentation of IP addresses > in the identity signature to be essential. Since you want to change > RFC 4474 to allow MITM editing of IP address information (thereby > weakening RFC 4474 protections in Jon's scenario), he doesn't like > your idea, I'm saying if you use identity-media, then you MUST use DTLS-SRTP (or at least the handshake part if you don't need actual encryptio, or a NULL encryption). That way it doesn't weaken anything. Also, nothing prevents anybody from using classic 4474 if you want to prevent nasty SBCs from mucking around with SDP: I can see enterprises doingbso between them. From jiri@iptel.org Tue Apr 7 01:52:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDFD3A67F5 for ; Tue, 7 Apr 2009 01:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llMw+SecyOxp for ; Tue, 7 Apr 2009 01:52:53 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id E3FD73A6816 for ; Tue, 7 Apr 2009 01:52:52 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id E81701811CF6; Tue, 7 Apr 2009 10:53:57 +0200 (CEST) Message-ID: <49DAE3F6.9050506@iptel.org> Date: Tue, 07 Apr 2009 07:26:14 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Francois Audet References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com><49D138D8.1040308@cisco.com><49D16BE1.3060307@iptel.org><49D3EEAA.1080006@iptel.org><4EE1C4F6-E2C1-4109-9703-CD1483E11DA0@softarmor.com> <0be201c9b480$cd88adb0$c4f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D3F795B@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List , "Uzelac, Adam" , Dan Wing , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 08:52:59 -0000 Francois Audet wrote: > >> All 5 techniques described in >> http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4 >> accomplish that using TLS, DTLS-SRTP, ICE, HIP, or ZRTP -- >> any of those choices has different tradeoffs. > > I'm puzzled by why we would do anything but the DTLS-SRTP (and TLS for TCP traffic). perhaps because zrtp does not require identity which fails to get to recepient because of SDP changes? -jiri > From root@core3.amsl.com Tue Apr 7 03:30:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 71E9528C0F7; Tue, 7 Apr 2009 03:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090407103001.71E9528C0F7@core3.amsl.com> Date: Tue, 7 Apr 2009 03:30:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-ua-privacy-07.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 10:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : UA-Driven Privacy Mechanism for SIP Author(s) : M. Munakata, et al. Filename : draft-ietf-sip-ua-privacy-07.txt Pages : 11 Date : 2009-04-07 This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUU) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-ua-privacy-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-07031828.I-D@ietf.org> --NextPart-- From AUDET@nortel.com Tue Apr 7 10:16:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7563A680B for ; Tue, 7 Apr 2009 10:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAwpfat4CwTs for ; Tue, 7 Apr 2009 10:16:00 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DA8EB3A67A6 for ; Tue, 7 Apr 2009 10:15:59 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n37HH2809346; Tue, 7 Apr 2009 17:17:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 12:16:12 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D50B892@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acmym8OanYrcZUyMQeinTO+WHiaadQFCLCCg References: From: "Francois Audet" To: "Christer Holmberg" , Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 17:16:00 -0000 Minor comment: It would improve readability of the Figures if the = vertical bars where ] included in the pictures. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Christer Holmberg Sent: Wednesday, April 01, 2009 00:31 To: sip@ietf.org Subject: [Sip] Draft new version: draft-ietf-sip-199-07 =09 =09 Hi,=20 I have put together a new version (-07) of the 199 draft, based on the = latest discussions.=20 The changes are in chapters 5 (new note added) and 6 (text simplified). = 100rel and SDP o/a impacts have also been added to chapters 5 and 6 (I = have still kept chapters 9 and 10, though). http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt = =20 Regards,=20 Christer=20 From attila.sipos@vegastream.com Tue Apr 7 12:20:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51F93A69D2 for ; Tue, 7 Apr 2009 12:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 H7Q-CHADVvrU for ; Tue, 7 Apr 2009 12:20:39 -0700 (PDT) Received: from cluster-f.mailcontrol.com (cluster-f.mailcontrol.com [85.115.62.190]) by core3.amsl.com (Postfix) with ESMTP id 3CB763A6765 for ; Tue, 7 Apr 2009 12:20:39 -0700 (PDT) Received: from rly05f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly05f.srv.mailcontrol.com (MailControl) with ESMTP id n37JLZ9J003881 for ; Tue, 7 Apr 2009 20:21:36 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly05f.srv.mailcontrol.com (MailControl) id n37JKe2W029410 for sip@ietf.org; Tue, 7 Apr 2009 20:20:40 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly05f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id n37JJMf9020916; Tue, 07 Apr 2009 20:20:40 +0100 (BST) Received: from EXVS02.nasstar-t1.net ([10.2.10.106]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 20:20:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B7B5.F8496367" Date: Tue, 7 Apr 2009 20:16:44 +0100 Message-ID: <680808427CF931459462C3D78CB5EC601CD001@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acmym8OanYrcZUyMQeinTO+WHiaadQFCLCCgAAQ71tE= References: <1ECE0EB50388174790F9694F77522CCF1D50B892@zrc2hxm0.corp.nortel.com> From: "Attila Sipos" To: "Francois Audet" , "Christer Holmberg" , X-OriginalArrivalTime: 07 Apr 2009 19:20:57.0018 (UTC) FILETIME=[FA20B1A0:01C9B7B5] X-Scanned-By: MailControl A_08_51_00 (www.mailcontrol.com) on 10.70.1.115 Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:20:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B7B5.F8496367 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Francois' comment about the diagram also brought to my attention the fact that figure 3 is probably "illegal" for RFCs - isn't there usually an 80 character line-length limit? =20 Anyway, I've "re-drawn" figure 3 and removed the word "leg" - this can obviously be made clear with an explanation. =20 UAC P1 P2 UAS_2 UAS_3 UAS_4 --- INVITE---> --- INVITE (2) -------------------> --- INVITE -----> --- INVITE (3) ------------> --- INVITE (4) ---------------------> <-- 18x (3) ---------------- <-- 18x (3) ----- <-- 18x (3) -- <-- 18x (4) ------------------------- <-- 18x (4) ----- <-- 18x (4) -- <-- 4xx (3) ---------------- --- ACK (3) ---------------> <-- 4xx (4) ------------------------- --- ACK (4) ------------------------> <-- 4xx (3) ---- --- ACK (3) ---> <-- 199 (3) -- <-- 199 (4) -- <-- 200 (2) ---------------------- <-- 200 (2) -- --- ACK (2) -> --- ACK (2) ---------------------> Only issue now is that this makes figure 3 inconsistent with the others. =20 =20 =20 ________________________________ From: sip-bounces@ietf.org on behalf of Francois Audet Sent: Tue 07/04/2009 18:16 To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 Minor comment: It would improve readability of the Figures if the vertical = bars where ] included in the pictures. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Wednesday, April 01, 2009 00:31 To: sip@ietf.org Subject: [Sip] Draft new version: draft-ietf-sip-199-07 =20=20=20=20=20=20=20 =20=20=20=20=20=20=20 Hi, I have put together a new version (-07) of the 199 draft, based on = the latest discussions. The changes are in chapters 5 (new note added) and 6 (text simplifi= ed). 100rel and SDP o/a impacts have also been added to chapters 5 and 6 (I= have still kept chapters 9 and 10, though). http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt =20 Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C9B7B5.F8496367 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] Draft new version: draft-ietf-sip-19= 9-07
Francois= ' comment about the diagram
also brought to my atten= tion the fact that figure 3
is probably "illegal" fo= r RFCs - isn't there usually
an 80 character line-len= gth limit?
 
Anyway, I've "re-drawn" = figure 3 and removed
the word "leg" - this ca= n obviously be made
clear with an explanatio= n.
&= nbsp;
 &n= bsp; UAC           P1&nbs= p;            &= nbsp; P2           &= nbsp;   UAS_2     UAS_3    UAS= _4
 &n= bsp;  --- INVITE--->
       &= nbsp;          --- INVITE (2) = ------------------->
        =           --- INVITE ----->=
            = ;            &n= bsp;          --- INVITE (3) -= ----------->
         &n= bsp;            = ;             -= -- INVITE (4) --------------------->
     &n= bsp;            = ;            &n= bsp;    <-- 18x (3) ----------------
   = ;            &n= bsp;  <-- 18x (3) -----
    <-- 18x (3) --
=             &nb= sp;            =           <-- 18x (4) -----= --------------------
        &nb= sp;         <-- 18x (4) -----    <-- 18x (4) --
     &nbs= p;            &= nbsp;           &nbs= p;    <-- 4xx (3) ----------------
   &= nbsp;           &nbs= p;            &= nbsp;      --- ACK (3) --------------->
&nbs= p;            &= nbsp;           &nbs= p;         <-- 4xx (4) ---------= ----------------
         &= nbsp;           &nbs= p;             = --- ACK (4) ------------------------>
     &= nbsp;            <= ;-- 4xx (3) ----
         &= nbsp;        --- ACK (3) --->
&nbs= p;   <-- 199 (3) --
    <-- 199 (4) --            &n= bsp;     <-- 200 (2) ----------------------
 = ;   <-- 200 (2) --
    --- ACK (2) ->
=             &nb= sp;     --- ACK (2) --------------------->

Only issue now is that this makes figure 3 inc= onsistent with the others.
 
 
 

From: sip-bounces@ietf.org on behalf of= Francois Audet
Sent: Tue 07/04/2009 18:16
To: Christer= Holmberg; sip@ietf.org
Subject: Re: [Sip] Draft new version: dra= ft-ietf-sip-199-07

Minor comment: It would improve readability of the Figure= s if the vertical bars where ]
included in the pictures.


____= ____________________________

      &nb= sp; From: sip-bounces@ietf.org [mai= lto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg
  = ;      Sent: Wednesday, April 01, 2009 00:31
&n= bsp;       To: sip@ietf.org
  &n= bsp;     Subject: [Sip] Draft new version: draft-ietf-s= ip-199-07
       
  &nbs= p;    


      &= nbsp; Hi,

        I have put toge= ther a new version (-07) of the 199 draft, based on the latest discussions.=

        The changes are in chapt= ers 5 (new note added) and 6 (text simplified). 100rel and SDP o/a impacts = have also been added to chapters 5 and 6 (I have still kept chapters 9 and = 10, though).

        http://www.ie= tf.org/internet-drafts/draft-ietf-sip-199-07.txt <http://www.ietf.org= /internet-drafts/draft-ietf-sip-199-07.txt> 

  = ;      Regards,

    &nb= sp;   Christer

___________________________________________= ____
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for= NEW development of the core SIP Protocol
Use sip-implementors@cs.columb= ia.edu for questions on current sip
Use sipping@ietf.org for new develop= ments on the application of sip



.

= ------_=_NextPart_001_01C9B7B5.F8496367-- From spencer@wonderhamster.org Tue Apr 7 12:37:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F513A6843 for ; Tue, 7 Apr 2009 12:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=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 7fb7JWzXGI3C for ; Tue, 7 Apr 2009 12:37:43 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 293D23A6765 for ; Tue, 7 Apr 2009 12:37:43 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LrH7e1Yow-000frK; Tue, 07 Apr 2009 15:38:19 -0400 Message-ID: From: "Spencer Dawkins" To: "Attila Sipos" , "Francois Audet" , "Christer Holmberg" , References: <1ECE0EB50388174790F9694F77522CCF1D50B892@zrc2hxm0.corp.nortel.com> <680808427CF931459462C3D78CB5EC601CD001@EXVS02.nasstar-t1.net> Date: Tue, 7 Apr 2009 14:37:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C9B78E.6DA99880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+11Ytd8lQpqFg4IkvFRwAIbymxrcMmtgjh0jG G7IorgEARIv1QnZAQ0mtLH8QOcXxSE2D5MMjrgee87YybmFxDc T3qZJ9msMNC1C0cx4FKbWhudZ2HWWt2Dn7OV/HCg/8= Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:37:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C9B78E.6DA99880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] Draft new version: draft-ietf-sip-199-07I apologize for this = post in advance (lowest added value post to this mailing list in some = time), but http://www.rfc-editor.org/rfc-editor/instructions2authors.txt says=20 B. Basic Formatting | 3.1 | o Only printable ASCII characters | 3.1(1), | 3.1(4) o No lines exceeding 72 characters | 3.1(2) [This is especially important for "as is" tables | and figures, which cannot be easily reformatted by| the RFC Editor.] =20 Thanks, Spencer ----- Original Message -----=20 From: Attila Sipos=20 To: Francois Audet ; Christer Holmberg ; sip@ietf.org=20 Sent: Tuesday, April 07, 2009 2:16 PM Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 Francois' comment about the diagram also brought to my attention the fact that figure 3 is probably "illegal" for RFCs - isn't there usually an 80 character line-length limit? Anyway, I've "re-drawn" figure 3 and removed the word "leg" - this can obviously be made clear with an explanation. UAC P1 P2 UAS_2 UAS_3 = UAS_4 --- INVITE---> --- INVITE (2) -------------------> --- INVITE -----> --- INVITE (3) ------------> --- INVITE (4) = ---------------------> <-- 18x (3) ---------------- <-- 18x (3) ----- <-- 18x (3) -- <-- 18x (4) = ------------------------- <-- 18x (4) ----- <-- 18x (4) -- <-- 4xx (3) ---------------- --- ACK (3) ---------------> <-- 4xx (4) = ------------------------- --- ACK (4) = ------------------------> <-- 4xx (3) ---- --- ACK (3) ---> <-- 199 (3) -- <-- 199 (4) -- <-- 200 (2) ---------------------- <-- 200 (2) -- --- ACK (2) -> --- ACK (2) ---------------------> Only issue now is that this makes figure 3 inconsistent with the = others. -------------------------------------------------------------------------= ----- From: sip-bounces@ietf.org on behalf of Francois Audet Sent: Tue 07/04/2009 18:16 To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 Minor comment: It would improve readability of the Figures if the = vertical bars where ] included in the pictures. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of Christer Holmberg Sent: Wednesday, April 01, 2009 00:31 To: sip@ietf.org Subject: [Sip] Draft new version: draft-ietf-sip-199-07 =20 =20 Hi, I have put together a new version (-07) of the 199 draft, = based on the latest discussions. The changes are in chapters 5 (new note added) and 6 (text = simplified). 100rel and SDP o/a impacts have also been added to chapters = 5 and 6 (I have still kept chapters 9 and 10, though). http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt = =20 Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip . -------------------------------------------------------------------------= ----- _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_NextPart_000_0039_01C9B78E.6DA99880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] Draft new version: = draft-ietf-sip-199-07
I apologize for this post in advance (lowest added = value post=20 to this mailing list in some time), but
 
ht= tp://www.rfc-editor.org/rfc-editor/instructions2authors.txt
 
says
 
B. Basic=20 Formatting          &nb= sp;           &nbs= p;            = ;    =20 | =20 3.1
           =             &= nbsp;           &n= bsp;           &nb= sp;          =20 |
    o   Only printable ASCII=20 characters          &nb= sp;        =20 | =20 3.1(1),
          &n= bsp;           &nb= sp;           &nbs= p;            = ;           =20 |    3.1(4)
    o   No lines=20 exceeding 72=20 characters          &nb= sp;       =20 |  3.1(2)
        [This is = especially=20 important for "as is" tables  =20 |
         and figures, which = cannot=20 be easily reformatted = by|
        =20 the RFC Editor.]  
 
Thanks,
 
Spencer
----- Original Message -----
From:=20 Attila Sipos
To: Francois Audet ; Christer Holmberg ; = sip@ietf.org =
Sent: Tuesday, April 07, 2009 = 2:16=20 PM
Subject: Re: [Sip] Draft new = version:=20 draft-ietf-sip-199-07

Francois' comment=20 about the diagram
also brought to my = attention the=20 fact that figure 3
is probably = "illegal" for RFCs -=20 isn't there usually
an 80 character = line-length=20 limit?
 
Anyway, I've = "re-drawn" figure 3=20 and removed
the word "leg" - = this can=20 obviously be made
clear with an=20 explanation.
 
  =20 UAC          =20 = P1            = ;  =20 = P2            = ;  =20 UAS_2     UAS_3    = UAS_4
   =20 ---=20 = INVITE--->
         &n= bsp;       =20 --- INVITE (2)=20 = ------------------->
       &nbs= p;         =20 --- INVITE=20 = ----->
          =             &= nbsp;           =20 --- INVITE (3)=20 = ------------>
         = ;            =             &= nbsp;=20 --- INVITE (4)=20 = --------------------->
       &n= bsp;           &nb= sp;           &nbs= p;  =20 <-- 18x (3)=20 = ----------------
         = ;        =20 <-- 18x (3) -----
    <-- 18x (3)=20 = --
           &= nbsp;           &n= bsp;          =20 <-- 18x (4)=20 = -------------------------
       &n= bsp;         =20 <-- 18x (4) -----
    <-- 18x (4)=20 = --
           &= nbsp;           &n= bsp;          =20 <-- 4xx (3)=20 = ----------------
         = ;            =             &= nbsp;=20 --- ACK (3)=20 = --------------->
        &n= bsp;           &nb= sp;           &nbs= p; =20 <-- 4xx (4)=20 = -------------------------
       &n= bsp;           &nb= sp;           &nbs= p;  =20 --- ACK (4)=20 = ------------------------>
       = ;          =20 <-- 4xx (3)=20 = ----
           = ;      =20 --- ACK (3) --->
    <-- 199 (3)=20 --
    <-- 199 (4)=20 = --
           &= nbsp;     =20 <-- 200 (2) ----------------------
    <-- 200 = (2)=20 --
    --- ACK (2)=20 = ->
          &nbs= p;      =20 --- ACK (2) --------------------->

Only issue now is that this makes figure = 3=20 inconsistent with the others.
 
 
 

From: sip-bounces@ietf.org on = behalf of=20 Francois Audet
Sent: Tue 07/04/2009 18:16
To: = Christer=20 Holmberg; sip@ietf.org
Subject: Re: [Sip] Draft new version: = draft-ietf-sip-199-07

Minor comment: It would improve readability of the = Figures if=20 the vertical bars where ]
included in the=20 = pictures.


________________________________

  =      =20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On Behalf=20 Of Christer Holmberg
        = Sent:=20 Wednesday, April 01, 2009 = 00:31
       =20 To: sip@ietf.org
        = Subject: [Sip]=20 Draft new version:=20 = draft-ietf-sip-199-07
       
&n= bsp;      


   &nb= sp;   =20 Hi,

        I have put = together a=20 new version (-07) of the 199 draft, based on the latest=20 discussions.

        The = changes are=20 in chapters 5 (new note added) and 6 (text simplified). 100rel and SDP = o/a=20 impacts have also been added to chapters 5 and 6 (I have still kept = chapters 9=20 and 10, though).

        ht= tp://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt=20 <ht= tp://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt> =

       =20 Regards,

       =20 Christer

_______________________________________________
Sip = mailing=20 list  https://www.ietf.org/m= ailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current sip
Use=20 sipping@ietf.org for new developments on the application of=20 sip



.

_______________________________________________
Sip mailing=20 list  https://www.ietf.org/mailman/listinfo/sip
This list is = for NEW=20 development of the core SIP Protocol
Use = sip-implementors@cs.columbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip ------=_NextPart_000_0039_01C9B78E.6DA99880-- From christer.holmberg@ericsson.com Tue Apr 7 12:40:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3C673A6CB9 for ; Tue, 7 Apr 2009 12:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.85 X-Spam-Level: X-Spam-Status: No, score=-5.85 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX8xZ-obKC4M for ; Tue, 7 Apr 2009 12:40:53 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8FEE23A68E5 for ; Tue, 7 Apr 2009 12:40:52 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 31DF820A2A; Tue, 7 Apr 2009 21:41:58 +0200 (CEST) X-AuditID: c1b4fb3c-a76e0bb000003b08-75-49dbac85bd66 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D8D5F20008; Tue, 7 Apr 2009 21:41:57 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 21:41:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B7B8.A45558E5" Date: Tue, 7 Apr 2009 21:40:01 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDw References: <1ECE0EB50388174790F9694F77522CCF1D50B892@zrc2hxm0.corp.nortel.com> <680808427CF931459462C3D78CB5EC601CD001@EXVS02.nasstar-t1.net> From: "Christer Holmberg" To: "Spencer Dawkins" , "Attila Sipos" , "Francois Audet" , X-OriginalArrivalTime: 07 Apr 2009 19:41:57.0649 (UTC) FILETIME=[E985B810:01C9B7B8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:40:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B7B8.A45558E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Spencer and Attila! I'll fix the flows. =20 Regards, =20 Christer ________________________________ From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 Sent: Tuesday, April 07, 2009 10:38 PM To: Attila Sipos; Francois Audet; Christer Holmberg; sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 I apologize for this post in advance (lowest added value post to this mailing list in some time), but =20 http://www.rfc-editor.org/rfc-editor/instructions2authors.txt =20 says=20 =20 B. Basic Formatting | 3.1 | o Only printable ASCII characters | 3.1(1), | 3.1(4) o No lines exceeding 72 characters | 3.1(2) [This is especially important for "as is" tables | and figures, which cannot be easily reformatted by| the RFC Editor.] =20 =20 Thanks, =20 Spencer ----- Original Message -----=20 From: Attila Sipos =20 To: Francois Audet ; Christer Holmberg ; sip@ietf.org=20 Sent: Tuesday, April 07, 2009 2:16 PM Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 Francois' comment about the diagram also brought to my attention the fact that figure 3 is probably "illegal" for RFCs - isn't there usually an 80 character line-length limit? =20 Anyway, I've "re-drawn" figure 3 and removed the word "leg" - this can obviously be made clear with an explanation. =20 UAC P1 P2 UAS_2 UAS_3 UAS_4 --- INVITE---> --- INVITE (2) -------------------> --- INVITE -----> --- INVITE (3) ------------> --- INVITE (4) ---------------------> <-- 18x (3) ---------------- <-- 18x (3) ----- <-- 18x (3) -- <-- 18x (4) ------------------------- <-- 18x (4) ----- <-- 18x (4) -- <-- 4xx (3) ---------------- --- ACK (3) ---------------> <-- 4xx (4) ------------------------- --- ACK (4) ------------------------> <-- 4xx (3) ---- --- ACK (3) ---> <-- 199 (3) -- <-- 199 (4) -- <-- 200 (2) ---------------------- <-- 200 (2) -- --- ACK (2) -> --- ACK (2) ---------------------> =09 Only issue now is that this makes figure 3 inconsistent with the others. =20 =20 =20 ________________________________ From: sip-bounces@ietf.org on behalf of Francois Audet Sent: Tue 07/04/2009 18:16 To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 =09 =09 Minor comment: It would improve readability of the Figures if the vertical bars where ] included in the pictures. =09 =09 ________________________________ =09 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, April 01, 2009 00:31 To: sip@ietf.org Subject: [Sip] Draft new version: draft-ietf-sip-199-07 =20 =20 =09 =09 Hi, =09 I have put together a new version (-07) of the 199 draft, based on the latest discussions. =09 The changes are in chapters 5 (new note added) and 6 (text simplified). 100rel and SDP o/a impacts have also been added to chapters 5 and 6 (I have still kept chapters 9 and 10, though). =09 =09 http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt =20 =09 Regards, =09 Christer =09 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 . =09 ________________________________ =09 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C9B7B8.A45558E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Sip] Draft new version: = draft-ietf-sip-199-07
Thanks Spencer and Attila! I'll fix the=20 flows.
 
Regards,
 
Christer

From: Spencer Dawkins=20 [mailto:spencer@wonderhamster.org]
Sent: Tuesday, April 07, = 2009=20 10:38 PM
To: Attila Sipos; Francois Audet; Christer Holmberg;=20 sip@ietf.org
Subject: Re: [Sip] Draft new version:=20 draft-ietf-sip-199-07

I apologize for this post in advance (lowest added = value post=20 to this mailing list in some time), but
 
ht= tp://www.rfc-editor.org/rfc-editor/instructions2authors.txt
 
says
 
B. Basic=20 Formatting          &nb= sp;           &nbs= p;            = ;    =20 | =20 3.1
           =             &= nbsp;           &n= bsp;           &nb= sp;          =20 |
    o   Only printable ASCII=20 characters          &nb= sp;        =20 | =20 3.1(1),
          &n= bsp;           &nb= sp;           &nbs= p;            = ;           =20 |    3.1(4)
    o   No lines=20 exceeding 72=20 characters          &nb= sp;       =20 |  3.1(2)
        [This is = especially=20 important for "as is" tables  =20 |
         and figures, which = cannot=20 be easily reformatted = by|
        =20 the RFC Editor.]  
 
Thanks,
 
Spencer
----- Original Message -----
From:=20 Attila Sipos
To: Francois Audet ; Christer Holmberg ; = sip@ietf.org =
Sent: Tuesday, April 07, 2009 = 2:16=20 PM
Subject: Re: [Sip] Draft new = version:=20 draft-ietf-sip-199-07

Francois' comment=20 about the diagram
also brought to my = attention the=20 fact that figure 3
is probably = "illegal" for RFCs -=20 isn't there usually
an 80 character = line-length=20 limit?
 
Anyway, I've = "re-drawn" figure 3=20 and removed
the word "leg" - = this can=20 obviously be made
clear with an=20 explanation.
 
  =20 UAC          =20 = P1            = ;  =20 = P2            = ;  =20 UAS_2     UAS_3    = UAS_4
   =20 ---=20 = INVITE--->
         &n= bsp;       =20 --- INVITE (2)=20 = ------------------->
       &nbs= p;         =20 --- INVITE=20 = ----->
          =             &= nbsp;           =20 --- INVITE (3)=20 = ------------>
         = ;            =             &= nbsp;=20 --- INVITE (4)=20 = --------------------->
       &n= bsp;           &nb= sp;           &nbs= p;  =20 <-- 18x (3)=20 = ----------------
         = ;        =20 <-- 18x (3) -----
    <-- 18x (3)=20 = --
           &= nbsp;           &n= bsp;          =20 <-- 18x (4)=20 = -------------------------
       &n= bsp;         =20 <-- 18x (4) -----
    <-- 18x (4)=20 = --
           &= nbsp;           &n= bsp;          =20 <-- 4xx (3)=20 = ----------------
         = ;            =             &= nbsp;=20 --- ACK (3)=20 = --------------->
        &n= bsp;           &nb= sp;           &nbs= p; =20 <-- 4xx (4)=20 = -------------------------
       &n= bsp;           &nb= sp;           &nbs= p;  =20 --- ACK (4)=20 = ------------------------>
       = ;          =20 <-- 4xx (3)=20 = ----
           = ;      =20 --- ACK (3) --->
    <-- 199 (3)=20 --
    <-- 199 (4)=20 = --
           &= nbsp;     =20 <-- 200 (2) ----------------------
    <-- 200 = (2)=20 --
    --- ACK (2)=20 = ->
          &nbs= p;      =20 --- ACK (2) --------------------->

Only issue now is that this makes figure = 3=20 inconsistent with the others.
 
 
 

From: sip-bounces@ietf.org on = behalf of=20 Francois Audet
Sent: Tue 07/04/2009 18:16
To: = Christer=20 Holmberg; sip@ietf.org
Subject: Re: [Sip] Draft new version: = draft-ietf-sip-199-07

Minor comment: It would improve readability of the = Figures if=20 the vertical bars where ]
included in the=20 = pictures.


________________________________

  =      =20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On Behalf=20 Of Christer Holmberg
        = Sent:=20 Wednesday, April 01, 2009 = 00:31
       =20 To: sip@ietf.org
        = Subject: [Sip]=20 Draft new version:=20 = draft-ietf-sip-199-07
       
&n= bsp;      


   &nb= sp;   =20 Hi,

        I have put = together a=20 new version (-07) of the 199 draft, based on the latest=20 discussions.

        The = changes are=20 in chapters 5 (new note added) and 6 (text simplified). 100rel and SDP = o/a=20 impacts have also been added to chapters 5 and 6 (I have still kept = chapters 9=20 and 10, though).

        ht= tp://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt=20 <ht= tp://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt> =

       =20 Regards,

       =20 Christer

_______________________________________________
Sip = mailing=20 list  https://www.ietf.org/m= ailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current sip
Use=20 sipping@ietf.org for new developments on the application of=20 sip



.

_______________________________________________
Sip mailing=20 list  https://www.ietf.org/mailman/listinfo/sip
This list is = for NEW=20 development of the core SIP Protocol
Use = sip-implementors@cs.columbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip ------_=_NextPart_001_01C9B7B8.A45558E5-- From drage@alcatel-lucent.com Tue Apr 7 16:16:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970F83A6951 for ; Tue, 7 Apr 2009 16:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8YS+ltJbRoe for ; Tue, 7 Apr 2009 16:16:37 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 8541028C128 for ; Tue, 7 Apr 2009 16:15:49 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n37NGtQT012189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 8 Apr 2009 01:16:55 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 8 Apr 2009 01:16:55 +0200 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" Date: Wed, 8 Apr 2009 01:16:54 +0200 Thread-Topic: Publication request for draft-ietf-sip-ua-privacy Thread-Index: Acm31HboL+Cy/1GKSjSUXqCFB7KPfA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D675848387@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: [Sip] Publication request for draft-ietf-sip-ua-privacy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 23:16:38 -0000 (As WG chair) I have just requested publication of draft-ietf-sip-ua-privacy as an inform= ational RFC. Following this mail is the proto shepherd writeup for this document. regards Keith PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-pri= vacy-07:=20 "Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509= =20 Certificates" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for publ= ication. Document history: - draft-munakata-sip-privacy-new-01 was submitted 18th June 2007 and=20 expired 20th December 2007. - draft-munakata-sip-privacy-new-01 was submitted 9th July 2007 and expired= =20 10th January 2008. - draft-ietf-sip-ua-privacy-00 was submitted 12th November 2007 and expired= =20 15th May 2008. - draft-ietf-sip-ua-privacy-01 was submitted 18th February 2008 and expired= =20 22nd August 2008. - draft-ietf-sip-ua-privacy-02 was submitted 14th July 2008 and expired=20 15th January 2009. - draft-ietf-sip-ua-privacy-03 was submitted 30th October 2008 and expires= =20 3rd May 2009. - draft-ietf-sip-ua-privacy-04 was submitted 5th February 2009 and expires= =20 9th August 2009. - draft-ietf-sip-ua-privacy-05 was submitted 9th February 2009 and expires= =20 13th August 2009. - draft-ietf-sip-ua-privacy-06 was submitted 5th March 2009 and expires 6th= =20 September 2009. - draft-ietf-sip-ua-privacy-06 was submitted 5th April 2009 and expires 7th= =20 October 2009. WGLC was announced in the SIP WG on 17th February 2009 to complete 2nd Marc= h 2009 on -03=20 version. Review was made and comments were received from: Michael Proctor, Cullen Je= nnings, John=20 Elwell. Previously during the discussion of this draft, review has been made and co= mments=20 received from Jonathan Rosenberg, Roland Jesske, Paul Kyzivat, John Elwell,= Cullen=20 Jennings, Krishna Prasad Kalluri. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had adequate review from working group members.=20 (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document shepherd considers that no external review from an external sp= ecialist is=20 necessary. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document shepherd has no specific concerns with any aspects of this doc= ument. There have been no IPR disclosures on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Full consensus exists on this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document has been reviewed against the guidelines in RFC 4485 and it is= believed=20 that the document is conformant with those guidelines. For ID-NITS the checks against idnits 2.11.08 reports no NITs found. It rai= ses a warning=20 that this document lacks a disclaimer for pre-RFC5378 work but was first su= bmitted this=20 became effective. It is understood no such disclaimer is required for this = internet- draft. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has separate sections for normative and informative references= . The=20 normative references have been checked and found to be normative. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document has no IANA registration requirements. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no material written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Technical summary. This document defines a guideline for a User Agent (UA) to generate an anon= ymous Session=20 Initiation Protocol (SIP) message by utilizing mechanisms such as Globally = Routable User=20 Agent URIs (GRUU) and Traversal Using Relays around NAT (TURN) without the = need for a=20 privacy service defined in RFC 3323. Working group summary. There is consensus in the working group to publish this document.=20 Document Quality There has been no specific indication of implementation. Personnel The document shepherd for this document was Keith Drage. The responsible Ar= ea Director=20 was Cullen Jennings. 'The IANA Expert(s) for the registries in this documen= t are .= From root@core3.amsl.com Wed Apr 8 07:15:02 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0E8E83A6E70; Wed, 8 Apr 2009 07:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090408141502.0E8E83A6E70@core3.amsl.com> Date: Wed, 8 Apr 2009 07:15:02 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-domain-certs-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 14:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Domain Certificates in the Session Initiation Protocol (SIP) Author(s) : V. Gurbani, et al. Filename : draft-ietf-sip-domain-certs-03.txt Pages : 17 Date : 2009-04-08 This document describes how to construct and interpret certain information in a X.509 PKIX-compliant certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of cetificates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-domain-certs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-08071245.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Apr 8 07:30:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D064E3A6AD8; Wed, 8 Apr 2009 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090408143001.D064E3A6AD8@core3.amsl.com> Date: Wed, 8 Apr 2009 07:30:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-eku-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 14:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates Author(s) : S. Lawrence, V. Gurbani Filename : draft-ietf-sip-eku-04.txt Pages : 9 Date : 2009-04-08 This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-eku-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-08071725.I-D@ietf.org> --NextPart-- From drage@alcatel-lucent.com Wed Apr 8 08:58:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E5B3A6A32 for ; Wed, 8 Apr 2009 08:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.177 X-Spam-Level: X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[AWL=-1.928, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5Caj-RK5kjk for ; Wed, 8 Apr 2009 08:58:56 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 912933A6856 for ; Wed, 8 Apr 2009 08:58:55 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n38G01Ru014491 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Apr 2009 18:00:01 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 8 Apr 2009 18:00:00 +0200 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" Date: Wed, 8 Apr 2009 17:59:59 +0200 Thread-Topic: Publication request for draft-ietf-sip-domain-certs Thread-Index: Acm4YxFt2U7LIK+PTL6NdZS8AscLdQ== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6758486E0@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "draft-ietf-sip-domain-certs@tools.ietf.org" Subject: [Sip] Publication request for draft-ietf-sip-domain-certs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 15:58:57 -0000 (As WG chair) I have just requested publication of draft-ietf-sip-domain-certs-03 as prop= osed standard. The proto writeup follows, for information. regards Keith ---------------------------------------------------------------- PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip-domain= -certs-03: "Domain Certificates in the Session Initiation Protocol (SIP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for publ= ication. Document history: - draft-gurbani-sip-domain-certs-00 was submitted 4th April 2006 and expire= d 6th October 2006. - draft-gurbani-sip-domain-certs-01 was submitted 26th June 2006 and expire= d 28th December 2006. - draft-gurbani-sip-domain-certs-02 was submitted 1st August 2006 and expir= ed 2nd February 2007. - draft-gurbani-sip-domain-certs-03 was submitted 2nd August 2006 and expir= ed 3rd February 2007. - draft-gurbani-sip-domain-certs-04 was submitted 5th March 2007 and expire= d 6th September 2007. - draft-gurbani-sip-domain-certs-05 was submitted 22nd June 2007 and expire= d 24th December 2007. - draft-gurbani-sip-domain-certs-06 was submitted 9th July 2007 and expired= 10th January 2008. - draft-ietf-sip-domain-certs-00 was submitted 8th November 2007 and expire= d 11th May 2008. - draft-ietf-sip-domain-certs-01 was submitted 14th July 2008 and expires 1= 5th January 2009. - draft-ietf-sip-domain-certs-02 was submitted 6th October 2008 and expires= 9th April 2009. - draft-ietf-sip-domain-certs-03 was submitted 7th April 2009 and expires 9= th October 2009. The document forms a normative dependency from draft-ietf-sip-connect-reuse= aside from being usable in its own right. WGLC was announced in the SIP WG on 22nd February 2008 to complete 7th Marc= h 2008 on -00 version.=20 Review was made and comments were received from: John Elwell, Robert Sparks= , Eric Rescorla, Jonathan Rosenberg, Cullen Jennings. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had adequate review from working group members.=20 (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document shepherd considers that no external review from an external sp= ecialist is necessary, apart from as follows. The document has been reviewed by members of the PKIX working group on a nu= mber of occasions, primarily Stephen Kent. The document has not had a separate security review, and that should theref= ore occur, although it has been reviewed by the security advisor to the RAI= area. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document shepherd has no specific concerns with any aspects of this doc= ument. There have been no IPR disclosures on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Full consensus exists on this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document has been reviewed against the guidelines in RFC 4485 and it is= believed that the document is conformant with those guidelines. For ID-NITS the checks against idnits 2.11.08 report NITS as follows. Summary: 0 errors (**), 1 warning (=3D=3D), 0 comments (--). draft-ietf-sip-eku and draft-ietf-sip-domain-certs (and draft-ietf-sip-conn= ect-reuse) have interdependent references, and the warning relates to one o= f these cross references. The latest versions of each will apply and it thi= s should sort itself out automatically on publication. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has separate sections for normative and informative references= . The normative references have been checked and found to be normative. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document has no IANA registration requirements. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does not contain any elements of formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Technical summary. This document describes how to construct and interpret certain information = in a X.509 PKIX-compliant certificate for use in a Session Initiation Proto= col (SIP) over Transport Layer Security (TLS) connection. More specificall= y, this document describes how to encode and extract the identity of a SIP = domain in a certificate and how to use that identity for SIP domain authent= ication. As such, this document is relevant both to implementors of SIP an= d to issuers of cetificates. Working group summary. There is consensus in the working group to publish this document.=20 Document Quality There has been no indication of implementation. Personnel The document shepherd for this document was Keith Drage. The responsible Ar= ea Director was Cullen Jennings. 'The IANA Expert(s) for the registries in = this document are . From drage@alcatel-lucent.com Wed Apr 8 09:05:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563923A69DE for ; Wed, 8 Apr 2009 09:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.145 X-Spam-Level: X-Spam-Status: No, score=-6.145 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GToKtGKyx78w for ; Wed, 8 Apr 2009 09:05:58 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 4A1663A6856 for ; Wed, 8 Apr 2009 09:05:57 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n38G70oW001107 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Apr 2009 18:07:00 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 8 Apr 2009 18:07:00 +0200 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" Date: Wed, 8 Apr 2009 18:06:59 +0200 Thread-Topic: Clarification on RFC 4458: SIP URIs for Applications such as Voicemail and Interactive Voice Response (IVR) Thread-Index: Acm4ZAuhHxUoU8AbSPyZU/azrqiw/Q== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6758486E4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: Cullen Jennings , Francois Audet , "Elwell, John" Subject: [Sip] Clarification on RFC 4458: SIP URIs for Applications such as Voicemail and Interactive Voice Response (IVR) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:05:59 -0000 RFC 4458 defines two SIP URI parameters. I can find no specific language in the document that indicates whether thes= e two URI parameters can be used independently of each other, or whether th= ere is an expectation that both URI parameters should only exist in the pre= sence of each other. Specifically does an implementation that only includes= the "cause" SIP URI parameter and not the "target" sip URI parameter confo= rm to this specification? All the text and examples seem to carry the implication that where one exis= ts, the other one will also.=20 Could one of the authors or some other interested party clarify what they b= elieve the intention is? regards Keith= From AUDET@nortel.com Wed Apr 8 09:09:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7993A6B3F for ; Wed, 8 Apr 2009 09:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BJdtmPDB621 for ; Wed, 8 Apr 2009 09:09:24 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C312A3A69FC for ; Wed, 8 Apr 2009 09:09:23 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n38G9oh00941; Wed, 8 Apr 2009 16:09:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 11:09:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D55CB68@zrc2hxm0.corp.nortel.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6758486E4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on RFC 4458: SIP URIs for Applications such as Voicemail and Interactive Voice Response (IVR) Thread-Index: Acm4ZAuhHxUoU8AbSPyZU/azrqiw/QAAEeeA References: <28B7C3AA2A7ABA4A841F11217ABE78D6758486E4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Francois Audet" To: "DRAGE, Keith (Keith)" , Cc: Cullen Jennings , "Elwell, John" Subject: Re: [Sip] Clarification on RFC 4458: SIP URIs for Applications such as Voicemail and Interactive Voice Response (IVR) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:09:24 -0000 I believe the intention was that target was mandatory, but not cause. I don't believe having cause but not target would make any sense.=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Wednesday, April 08, 2009 09:07 > To: sip@ietf.org > Cc: Cullen Jennings; Audet, Francois (SC100:3055); Elwell, John > Subject: Clarification on RFC 4458: SIP URIs for Applications=20 > such as Voicemail and Interactive Voice Response (IVR) >=20 > RFC 4458 defines two SIP URI parameters. >=20 > I can find no specific language in the document that=20 > indicates whether these two URI parameters can be used=20 > independently of each other, or whether there is an=20 > expectation that both URI parameters should only exist in the=20 > presence of each other. Specifically does an implementation=20 > that only includes the "cause" SIP URI parameter and not the=20 > "target" sip URI parameter conform to this specification? >=20 > All the text and examples seem to carry the implication that=20 > where one exists, the other one will also.=20 >=20 > Could one of the authors or some other interested party=20 > clarify what they believe the intention is? >=20 > regards >=20 > Keith >=20 From ya-ching.tan@nsn.com Wed Apr 8 09:39:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A3A28C167 for ; Wed, 8 Apr 2009 09:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVjY3yp+rzGJ for ; Wed, 8 Apr 2009 09:39:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B176728C1C3 for ; Wed, 8 Apr 2009 09:39:03 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n38Ge8sw012378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Apr 2009 18:40:08 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n38Ge8AX019293; Wed, 8 Apr 2009 18:40:08 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Apr 2009 18:40:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 18:40:08 +0200 Message-ID: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/A= References: From: "Tan, Ya Ching (NSN - DE/Munich)" To: "ext Christer Holmberg" X-OriginalArrivalTime: 08 Apr 2009 16:40:08.0302 (UTC) FILETIME=[AD7538E0:01C9B868] Cc: sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:39:05 -0000 Some comments : 1) Section 6 Proxy behaviour: =20 "When a proxy receives a 199 response, it MUST process the response as any other non-100 provisional responses." =20 Do we really want this on a 199-aware proxy ? It is not stated here that the 199 response received by the proxy is only recognised if sent in an existing early dialog. If the 199 response is received by a 199-aware proxy out of any existing early dialog, should the dialog-stateful proxy create a new dialog with the new To tag and allocate resources "as any other non-100 provisional responses" ? =20 =20 Another condition should be added to the list of conditions that must be satisfied for the generation of the 199 by the proxy : - No 2xx response has been sent on the server transaction As 199 is meant to meet REQ 1 "to indicate to the UAC that an early dialog has been terminated BEFORE A FINAL RESPONSE is sent", and according to RFC3261/16.7 bullet 5: "After a final response has been sent on the server transaction, the following responses MUST be forwarded immediately: - Any 2xx response to an INVITE request A stateful proxy MUST NOT immediately forward any other responses." 199 belongs to "any other responses" which MUST not be forwarded. 2) Section 7 Backward compatibilility "The 199 Early Dialog Terminated response code does not "replace" a final response. A final response is always sent, after one or many 199 provisional responses have been sent." A final response is NOT always sent. If the forking has resulted in at least one 2xx being sent on the server transaction, no 3xx/4xx/5xx/6xx is allowed to be sent to the same server transaction after the 2xx. So these early dialogs which receive non-2xx final response AFTER a first 2xx final response will not get 199 but will only be considered terminated by the UAC 64*T1 seconds after the reception of the first 2xx response. Even those early dialogs for which 199 responses have been sent (because the final responses were received before the first 2xx) will not receive a final response. RFC3261/13.2.2.4: "The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive."=20 =20 3) Minor comments: Section 4.1 : "...When the P-Early-Media header is used..." Add [RFC5009] after the "header". Section 6 : "...., it generates a unique Via header branch parameter value for each fork". Replace "fork" with "forked leg" because the term "fork" has not be defined officially or used in RFC 3261 for this purpose. Section 6: "A forking proxy which supports generating of 199 response codes..." Replace "codes" with "code". Regards, Ya-Ching =20 =20 ________________________________ =09 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, April 01, 2009 00:31 To: sip@ietf.org Subject: [Sip] Draft new version: draft-ietf-sip-199-07 =20 =20 =09 =09 Hi, =09 I have put together a new version (-07) of the 199 draft, based on the latest discussions. =09 The changes are in chapters 5 (new note added) and 6 (text simplified). 100rel and SDP o/a impacts have also been added to chapters 5 and 6 (I have still kept chapters 9 and 10, though). =09 =09 http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt =20 =09 Regards, =09 Christer =09 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 . ________________________________ _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From drage@alcatel-lucent.com Wed Apr 8 09:58:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0F53A6E86 for ; Wed, 8 Apr 2009 09:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ObqnGPBbO3I for ; Wed, 8 Apr 2009 09:58:04 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 306813A6E85 for ; Wed, 8 Apr 2009 09:58:04 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n38GxAhp025719 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Apr 2009 18:59:10 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 8 Apr 2009 18:59:10 +0200 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" Date: Wed, 8 Apr 2009 18:59:06 +0200 Thread-Topic: Publication request for draft-ietf-sip-eku Thread-Index: Acm4a1P5diM849OxRAOMe1KoOAuWFg== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D675848701@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "draft-ietf-sip-eku@tools.ietf.org" Subject: [Sip] Publication request for draft-ietf-sip-eku X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:58:05 -0000 (As WG chair) I have just requested publication of draft-ietf-sip-eku-04 as proposed stan= dard. The proto writeup follows, for information. regards Keith ---------------------------------------------------------------------------= --------- PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-04= : "Using=20 Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certif= icates" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for publ= ication. Document history: - The document was separated out from draft-gurbani-sip-domain-certs-06=20 which was submitted 9th July 2007 and expired 10th January 2008. - draft-ietf-sip-eku-00 was submitted 8th November 2007 and expires 11th=20 May 2008. - draft-ietf-sip-eku-01 was submitted 18th February 2008 and expired 21st=20 August 2008. - draft-ietf-sip-eku-02 was submitted 11th July 2008 and expires 12 January= =20 2009. - draft-ietf-sip-eku-03 was submitted 6th October 2008 and expires 9th=20 April 2009. - draft-ietf-sip-eku-04 was submitted 7th April 2009 and expires 9th=20 October 2009. The document forms a normative dependency from draft-ietf-sip-domain-certs = aside from=20 being usable in its own right. WGLC was announced in the SIP WG on 22nd February 2008 to complete 7th Marc= h 2008 on -00=20 version. Review was made and comments were received from: John Elwell, Eric Rescorla= . (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had adequate review from working group members.=20 (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document shepherd considers that no external review from an external sp= ecialist is=20 necessary, apart from as follows. The document has been reviewed by members of the PKIX working group on a nu= mber of=20 occasions, primarily Stephen Kent. The document has not had a separate security review, and that should theref= ore occur,=20 although it has been reviewed by the security advisor to the RAI area. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document shepherd has no specific concerns with any aspects of this doc= ument. There have been no IPR disclosures on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Full consensus exists on this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document has been reviewed against the guidelines in RFC 4485 and it is= believed=20 that the document is conformant with those guidelines. For ID-NITS the checks against idnits 2.11.08 report NITS as follows. Summary: 1 error (**), 0 warnings (=3D=3D), 3 comments (--). The error relates to an indication that it does not contain an "Introductio= n".=20 However document does contain an early section "Problem Statement" which se= rves=20 exactly this function. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has separate sections for normative and informative references= . The=20 normative references have been checked and found to be normative. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document has no IANA registration requirements. The object identifiers = forms part of=20 the existing allocation made by IANA to the PKIX working group. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document defines an object identifier using the formal language ASN.1. = This=20 definition is trivial and has been confirmed by visual inspection. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Technical summary. This memo documents an extended key usage (EKU) X.509 certificate extension= for=20 restricting the applicability of a certificate to use with a Session Initia= tion=20 Protocol (SIP) service. As such, in addition to providing rules for SIP=20 implementations, this memo also provides guidance to issuers of certificate= s for=20 use with SIP. Working group summary. There is consensus in the working group to publish this document.=20 Document Quality There has been no indication of implementation. Personnel The document shepherd for this document was Keith Drage. The responsible Ar= ea Director=20 was Cullen Jennings. 'The IANA Expert(s) for the registries in this documen= t are . From christer.holmberg@ericsson.com Wed Apr 8 10:19:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D323A6E77 for ; Wed, 8 Apr 2009 10:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.835 X-Spam-Level: X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Djgxh7MDV1aU for ; Wed, 8 Apr 2009 10:19:54 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A383E3A6E56 for ; Wed, 8 Apr 2009 10:19:53 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9058320173; Wed, 8 Apr 2009 19:20:59 +0200 (CEST) X-AuditID: c1b4fb3e-ab81ebb0000024d5-a4-49dcdcfbbbc6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 614FD200DB; Wed, 8 Apr 2009 19:20:59 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 19:20:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 19:20:58 +0200 Message-ID: In-Reply-To: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUA== References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> From: "Christer Holmberg" To: "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 08 Apr 2009 17:20:59.0225 (UTC) FILETIME=[62526490:01C9B86E] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 17:19:55 -0000 Hi,=20 >1) Section 6 Proxy behaviour: >=20 >"When a proxy receives a 199 response, it MUST process the response as any other non-100 provisional responses." >=20 >Do we really want this on a 199-aware proxy ? It is not stated here that the 199 response received by the proxy is only=20 >recognised if sent in an existing early dialog. If the 199 response is received by a 199-aware proxy out of any existing=20 >early dialog, should the dialog-stateful proxy create a new dialog with the new To tag and allocate resources "as any=20 >other non-100 provisional responses" ? =20 Receiving 199 out-of-dialog is an error case, and I think it's an implementation issue how those are handled. We normally don't specify that. I also think it is quite clear that a proxy which support 199 would not create a new dialog. ------ >Another condition should be added to the list of conditions that must be satisfied for the generation of the 199 by the=20 >proxy : > >- No 2xx response has been sent on the server transaction > >As 199 is meant to meet REQ 1 "to indicate to the UAC that an early dialog has been terminated BEFORE A FINAL RESPONSE is=20 >sent", and according to RFC3261/16.7 bullet 5: > > > "After a final response has been sent on the server transaction, > the following responses MUST be forwarded immediately: > > - Any 2xx response to an INVITE request > > A stateful proxy MUST NOT immediately forward any other > responses." > >199 belongs to "any other responses" which MUST not be forwarded. I guess the text you propose applies to any final response (not only 2xx) sent by the forking proxy.=20 I guess I could add some text, eventhough I think it is obvious. When the forking proxy forwards a final response it terminates all early dialogs. ----- >2) Section 7 Backward compatibilility > >"The 199 Early Dialog Terminated response code does not "replace" a final response. A final response is always sent,=20 >after one or many 199 provisional responses have been sent." > >A final response is NOT always sent. If the forking has resulted in at least one 2xx being sent on the server=20 >transaction, no 3xx/4xx/5xx/6xx is allowed to be sent to the same server transaction after the 2xx. Well, in that case a final response (the 2xx) HAS been sent. The text doesn't say that a final response must be sent on each early dialog. >So these early dialogs which receive non-2xx final response AFTER a first 2xx final response will not get 199 but will=20 >only be considered terminated by the UAC 64*T1 seconds after the reception of the first 2xx response. Even those early=20 >dialogs for which 199 responses have been sent (because the final responses were received before the first 2xx) will not=20 >receive a final response. > >RFC3261/13.2.2.4: > > "The UAC core considers the INVITE transaction completed 64*T1 seconds > after the reception of the first 2xx response. At this point all the > early dialogs that have not transitioned to established dialogs are > terminated. Once the INVITE transaction is considered completed by > the UAC core, no more new 2xx responses are expected to arrive."=20 The intention is to say that IF the server has an intention to send a final response on a specific dialog, it must not "replace" that final response with a 199. =20 ------ >3) Minor comments: > > Section 4.1 : "...When the P-Early-Media header is used..." > Add [RFC5009] after the "header". I will do that. ------ >Section 6 : "...., it generates a unique Via header branch parameter value for each fork". >Replace "fork" with "forked leg" because the term "fork" has not be defined officially or used in RFC 3261 for this=20 >purpose. I will do that. ------ >Section 6: "A forking proxy which supports generating of 199 response codes..." >Replace "codes" with "code". I would propose to say "generating of 199 responses..." instead. That is more alligned with the wording in other places of the document. ------ Thank You very much for your comments! Regards, Christer =09 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, April 01, 2009 00:31 To: sip@ietf.org Subject: [Sip] Draft new version: draft-ietf-sip-199-07 =20 =20 =09 =09 Hi, =09 I have put together a new version (-07) of the 199 draft, based on the latest discussions. =09 The changes are in chapters 5 (new note added) and 6 (text simplified). 100rel and SDP o/a impacts have also been added to chapters 5 and 6 (I have still kept chapters 9 and 10, though). =09 =09 http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt =20 =09 Regards, =09 Christer =09 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 . ________________________________ _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From christer.holmberg@ericsson.com Wed Apr 8 13:08:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332943A6E5C for ; Wed, 8 Apr 2009 13:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.838 X-Spam-Level: X-Spam-Status: No, score=-5.838 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Src+BMclX7Mg for ; Wed, 8 Apr 2009 13:07:59 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2CBE428B56A for ; Wed, 8 Apr 2009 13:07:59 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A3BF6206D8; Wed, 8 Apr 2009 22:09:04 +0200 (CEST) X-AuditID: c1b4fb3e-b0027bb0000024d5-98-49dd0460a40f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7E24E204B4; Wed, 8 Apr 2009 22:09:04 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 22:09:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 22:09:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 - comment on section 7 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUAAGmYbA References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> From: "Christer Holmberg" To: "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 08 Apr 2009 20:09:04.0380 (UTC) FILETIME=[DD8AEBC0:01C9B885] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 - comment on section 7 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 20:08:00 -0000 Hi,=20 ----- >2) Section 7 Backward compatibilility > >"The 199 Early Dialog Terminated response code does not "replace" a >final response. A final response is always sent, after one or many 199 provisional responses have been sent." > >A final response is NOT always sent. If the forking has resulted in at >least one 2xx being sent on the server transaction, no 3xx/4xx/5xx/6xx is allowed to be sent to the same >server transaction after the 2xx. > >So these early dialogs which receive non-2xx final response AFTER a first 2xx final response will not get 199 but will=20 >only be considered terminated by the UAC 64*T1 seconds after the reception of the first 2xx response. Even those early=20 >dialogs for which 199 responses have been sent (because the final responses were received before the first 2xx) will not=20 >receive a final response. > >RFC3261/13.2.2.4: > >"The UAC core considers the INVITE transaction completed 64*T1 seconds >after the reception of the first 2xx response. At this point all >the early dialogs that have not transitioned to established dialogs are >terminated. Once the INVITE transaction is considered completed by >the UAC core, no more new 2xx responses are expected to arrive."=20 > I propose the following text: "The 199 Early Dialog Terminated response code does not "replace" a final response. A final response must always be sent when mandated by the procedures in RFC3261." I think that would clarify that we are not modifying the core SIP rules on sending final responses. Regards, Christer From drage@alcatel-lucent.com Wed Apr 8 15:44:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6013C3A6B2E for ; Wed, 8 Apr 2009 15:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIpDTsxqNHRB for ; Wed, 8 Apr 2009 15:44:50 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 4B0243A6A63 for ; Wed, 8 Apr 2009 15:44:50 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n38Mjsoq028563 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Apr 2009 00:45:54 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 9 Apr 2009 00:45:54 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , "Tan, Ya Ching (NSN - DE/Munich)" Date: Thu, 9 Apr 2009 00:45:52 +0200 Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 - comment on section 7 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUAAGmYbAAAWaGlA= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67584874B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> In-Reply-To: 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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "sip@ietf.org" Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 - comment on section 7 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 22:44:51 -0000 Is that a "MUST" or something that is not must like "RFC 3261 specifies whe= n a final response is sent." Keith=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Christer Holmberg > Sent: Wednesday, April 08, 2009 9:09 PM > To: Tan, Ya Ching (NSN - DE/Munich) > Cc: sip@ietf.org > Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 -=20 > comment on section 7 >=20 >=20 > Hi,=20 >=20 > ----- >=20 > >2) Section 7 Backward compatibilility > > > >"The 199 Early Dialog Terminated response code does not "replace" a=20 > >final response. A final response is always sent, after one=20 > or many 199 > provisional responses have been sent." > > > >A final response is NOT always sent. If the forking has=20 > resulted in at=20 > >least one 2xx being sent on the server transaction, no=20 > 3xx/4xx/5xx/6xx > is allowed to be sent to the same > >server transaction after the 2xx. > > > >So these early dialogs which receive non-2xx final response AFTER a > first 2xx final response will not get 199 but will=20 > >only be considered terminated by the UAC 64*T1 seconds after the > reception of the first 2xx response. Even those early=20 > >dialogs for which 199 responses have been sent (because the final > responses were received before the first 2xx) will not=20 > >receive a final response. > > > >RFC3261/13.2.2.4: > > > >"The UAC core considers the INVITE transaction completed=20 > 64*T1 seconds=20 > >after the reception of the first 2xx response. At this=20 > point all the=20 > >early dialogs that have not transitioned to established dialogs are=20 > >terminated. Once the INVITE transaction is considered=20 > completed by the=20 > >UAC core, no more new 2xx responses are expected to arrive." > > >=20 > I propose the following text: >=20 > "The 199 Early Dialog Terminated response code does not=20 > "replace" a final response. A final response must always be=20 > sent when mandated by the procedures in RFC3261." >=20 > I think that would clarify that we are not modifying the core=20 > SIP rules on sending final responses. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip > = From jon.peterson@neustar.biz Wed Apr 8 19:10:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E273A6B81 for ; Wed, 8 Apr 2009 19:10:14 -0700 (PDT) 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=[AWL=0.300, 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 jkqoXEmZbJVg for ; Wed, 8 Apr 2009 19:10:09 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id ECD413A6B07 for ; Wed, 8 Apr 2009 19:10:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1239243072; x=1239329472; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=QT+rclQw4HwWR3L9gkHaDpTd9Dzu3qTBwpnbruh6+/y/tTMQV65KI1Sk2SI289CqhSDYLcOyRnU+7P EO5zV1SA== Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.12881840; Wed, 08 Apr 2009 22:10:58 -0400 Received: from 10.31.13.113 ([10.31.13.113]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Thu, 9 Apr 2009 02:10:54 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 08 Apr 2009 19:10:53 -0700 From: Jon Peterson To: Francois Audet , Dean Willis Message-ID: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZV In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 02:10:14 -0000 I think I've said in the past that the IP address and port remain relevant because their soundness is a necessary condition for the delivery of media, and by extension the employment of mechanisms like DTLS-SRTP. If we remove the IP address and port from the protection domain of rendezvous layer security entirely, then either an MITM or a cut-and-paste attacker could exploit those SDP lines to deny service, for example, in a manner that will not be detected by the recipient until they find their media goes AWOL. That's basically why I think the alteration of those lines should be a detectable condition in the rendezvous layer, and why I've argued we should have data origin authentication for that information. That doesn't necessarily mean we need it in the form that RFC4474 currently provides it - various sorts of patch-and-sign mechanisms would also be fine with me. But with authentication, if media isn't reaching your interlocutor because it's drifting out into space, at least you know who told you to aim it there - which is, I believe, a valuable security property. Most of my concerns here are really about layer violations, about how many security functions we can defer to the media layer and how many must reside in the rendezvous layer in order to meet our requirements. The primitives that establish and maintain sessions, I believe, require protection in the rendezvous layer - DTLS-SRTP isn't going to protect you against a forged BYE, say. If the aggregate security that the system provides does not prevent an attack that cheap, I think we've accomplished less than we can and should. I also think that having enough credible information in a SIP request that a recipient has reasonable grounds to authorize or reject it is a good general design goal for our security work; provisionally accepting requests and initiating media (DTLS-SRTP) in order to determine whether or not the dialog is authorized protects against certain threats, but broadly I think it doesn't address threats where an attacker/impersonator can accomplish their goals without ever establishing a session. If we think about, I suspect we'll find there are actually quite a few of those. Jon Peterson NeuStar, Inc. On 4/6/09 9:54 PM, "Francois Audet" wrote: >> >> Yes, but it does so at the expense of weakening RFC 4474 when it is >> used without DTLS. >> >> I believe Jon has said that he wishes to be able to use signaling >> identity without DTLS and considers the presentation of IP addresses >> in the identity signature to be essential. Since you want to change >> RFC 4474 to allow MITM editing of IP address information (thereby >> weakening RFC 4474 protections in Jon's scenario), he doesn't like >> your idea, > > I'm saying if you use identity-media, then you MUST use DTLS-SRTP (or > at least the handshake part if you don't need actual encryptio, or a > NULL encryption). > > That way it doesn't weaken anything. Also, nothing prevents anybody > from using classic 4474 if you want to prevent nasty SBCs from mucking > around with SDP: I can see enterprises doingbso between them. > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From marianne.mohali@orange-ftgroup.com Wed Apr 8 21:32:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B2F3A6933 for ; Wed, 8 Apr 2009 21:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-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 i0Ar4RobTD+k for ; Wed, 8 Apr 2009 21:32:07 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 6B2A13A6BD7 for ; Wed, 8 Apr 2009 21:31:23 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Apr 2009 06:32:20 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 06:32:17 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026065E70D3@ftrdmel2> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D55CB68@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Clarification on RFC 4458: SIP URIs for Applications suchas Voicemail and Interactive Voice Response (IVR) Thread-Index: Acm4ZAuhHxUoU8AbSPyZU/azrqiw/QAAEeeAABF2MuA= References: <28B7C3AA2A7ABA4A841F11217ABE78D6758486E4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF1D55CB68@zrc2hxm0.corp.nortel.com> From: To: , , X-OriginalArrivalTime: 09 Apr 2009 04:32:20.0053 (UTC) FILETIME=[2B90F850:01C9B8CC] Cc: fluffy@cisco.com, john.elwell@siemens.com Subject: Re: [Sip] Clarification on RFC 4458: SIP URIs for Applications suchas Voicemail and Interactive Voice Response (IVR) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 04:32:08 -0000 Hi,=20 It is certainly true for those parameters in the R-URI but in the = History-Info header it is less obivous because if RFC4244 is respected, = the retargeting is yet present in a hi-entry (the proof is that the = target parameter has not been especially recommended to be used in 3GPP = for CDIV service). The benefit to add the target parameter in the R-URI = in the hi-entry is to have in the same hi-entry the redirecting user and = the cause-param. So that we can be sure of the redirecting user identity = (which could be in an other hi-entry than the one "just before"). But = after that, it is still necessary to search in hi-entries the entry = concerning the redirecting address to have the Privacy indication (eg. = to deliver or not the redireting user identity to the diverted-to user) = and to know if the retargeting is caused by a SIP response or not (if = the Reason header is escaped). Regards, Marianne -----Message d'origine----- De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de = Francois Audet Envoy=E9 : mercredi 8 avril 2009 18:10 =C0 : DRAGE, Keith (Keith); sip@ietf.org Cc : Cullen Jennings; Elwell,John Objet : Re: [Sip] Clarification on RFC 4458: SIP URIs for Applications = suchas Voicemail and Interactive Voice Response (IVR) I believe the intention was that target was mandatory, but not cause. I don't believe having cause but not target would make any sense.=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Wednesday, April 08, 2009 09:07 > To: sip@ietf.org > Cc: Cullen Jennings; Audet, Francois (SC100:3055); Elwell, John > Subject: Clarification on RFC 4458: SIP URIs for Applications such as=20 > Voicemail and Interactive Voice Response (IVR) >=20 > RFC 4458 defines two SIP URI parameters. >=20 > I can find no specific language in the document that indicates whether = > these two URI parameters can be used independently of each other, or=20 > whether there is an expectation that both URI parameters should only=20 > exist in the presence of each other. Specifically does an=20 > implementation that only includes the "cause" SIP URI parameter and=20 > not the "target" sip URI parameter conform to this specification? >=20 > All the text and examples seem to carry the implication that where one = > exists, the other one will also. >=20 > Could one of the authors or some other interested party clarify what=20 > they believe the intention is? >=20 > regards >=20 > Keith >=20 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu for questions on current sip Use = sipping@ietf.org for new developments on the application of sip From AUDET@nortel.com Wed Apr 8 21:42:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A563A68B1 for ; Wed, 8 Apr 2009 21:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.067 X-Spam-Level: X-Spam-Status: No, score=-5.067 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GRg3oWe6VWr for ; Wed, 8 Apr 2009 21:42:34 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id CECF73A68D0 for ; Wed, 8 Apr 2009 21:42:33 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n394gwX25052; Thu, 9 Apr 2009 04:42:59 GMT Received: from 47.103.119.44 ([47.103.119.44]) by zrc2hxm0.corp.nortel.com ([47.103.119.44]) with Microsoft Exchange Server HTTP-DAV ; Thu, 9 Apr 2009 04:42:53 +0000 References: <28B7C3AA2A7ABA4A841F11217ABE78D6758486E4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF1D55CB68@zrc2hxm0.corp.nortel.com> <7DBAFEC6A76F3E42817DF1EBE64CB026065E70D3@ftrdmel2> Message-ID: <14D40684-C8E6-4293-8475-36A2E78C2B90@nortel.com> From: "Francois Audet" To: thread-topic: [Sip] Clarification on RFC 4458: SIP URIs for Applications suchas Voicemail and Interactive Voice Response (IVR) thread-index: Acm4zaUf7Rc0wN4LRxaJ2RhkeTUSJg== In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026065E70D3@ftrdmel2> Content-Type: text/plain; format=flowed; delsp=yes; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 (iPod Mail 5H11a) Date: Wed, 8 Apr 2009 21:42:52 -0700 Cc: sip@ietf.org, fluffy@cisco.com, drage@alcatel-lucent.com, john.elwell@siemens.com Subject: Re: [Sip] Clarification on RFC 4458: SIP URIs for Applications suchas Voicemail and Interactive Voice Response (IVR) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 04:42:35 -0000 VGhhbmtzLCBnb29kIHBvaW50LiBJIHdhcyBvbmx5IHRoaW5raW5nIG9mIHRoZSBSLVVSSS4NCg0K T24gQXByIDgsIDIwMDksIGF0IDIxOjMyLCAibWFyaWFubmUubW9oYWxpQG9yYW5nZS1mdGdyb3Vw LmNvbSIgPG1hcmlhbm5lLm1vaGFsaUBvcmFuZ2UtZnRncm91cC5jb20gDQogPiB3cm90ZToNCg0K PiBIaSwNCj4NCj4gSXQgaXMgY2VydGFpbmx5IHRydWUgZm9yIHRob3NlIHBhcmFtZXRlcnMgaW4g dGhlIFItVVJJIGJ1dCBpbiB0aGUgIA0KPiBIaXN0b3J5LUluZm8gaGVhZGVyIGl0IGlzIGxlc3Mg b2Jpdm91cyBiZWNhdXNlIGlmIFJGQzQyNDQgaXMgIA0KPiByZXNwZWN0ZWQsIHRoZSByZXRhcmdl dGluZyBpcyB5ZXQgcHJlc2VudCBpbiBhIGhpLWVudHJ5ICh0aGUgcHJvb2YgIA0KPiBpcyB0aGF0 IHRoZSB0YXJnZXQgcGFyYW1ldGVyIGhhcyBub3QgYmVlbiBlc3BlY2lhbGx5IHJlY29tbWVuZGVk IHRvICANCj4gYmUgdXNlZCBpbiAzR1BQIGZvciBDRElWIHNlcnZpY2UpLiBUaGUgYmVuZWZpdCB0 byBhZGQgdGhlIHRhcmdldCAgDQo+IHBhcmFtZXRlciBpbiB0aGUgUi1VUkkgaW4gdGhlIGhpLWVu dHJ5IGlzIHRvIGhhdmUgaW4gdGhlIHNhbWUgaGktIA0KPiBlbnRyeSB0aGUgcmVkaXJlY3Rpbmcg dXNlciBhbmQgdGhlIGNhdXNlLXBhcmFtLiBTbyB0aGF0IHdlIGNhbiBiZSAgDQo+IHN1cmUgb2Yg dGhlIHJlZGlyZWN0aW5nIHVzZXIgaWRlbnRpdHkgKHdoaWNoIGNvdWxkIGJlIGluIGFuIG90aGVy IGhpLSANCj4gZW50cnkgdGhhbiB0aGUgb25lICJqdXN0IGJlZm9yZSIpLiBCdXQgYWZ0ZXIgdGhh dCwgaXQgaXMgc3RpbGwgIA0KPiBuZWNlc3NhcnkgdG8gc2VhcmNoIGluIGhpLWVudHJpZXMgdGhl IGVudHJ5IGNvbmNlcm5pbmcgdGhlICANCj4gcmVkaXJlY3RpbmcgYWRkcmVzcyB0byBoYXZlIHRo ZSBQcml2YWN5IGluZGljYXRpb24gKGVnLiB0byBkZWxpdmVyICANCj4gb3Igbm90IHRoZSByZWRp cmV0aW5nIHVzZXIgaWRlbnRpdHkgdG8gdGhlIGRpdmVydGVkLXRvIHVzZXIpIGFuZCB0byAgDQo+ IGtub3cgaWYgdGhlIHJldGFyZ2V0aW5nIGlzIGNhdXNlZCBieSBhIFNJUCByZXNwb25zZSBvciBu b3QgKGlmIHRoZSAgDQo+IFJlYXNvbiBoZWFkZXIgaXMgZXNjYXBlZCkuDQo+DQo+IFJlZ2FyZHMs DQo+IE1hcmlhbm5lDQo+DQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZSA6IHNp cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBh cnQgIA0KPiBkZSBGcmFuY29pcyBBdWRldA0KPiBFbnZvecOpIDogbWVyY3JlZGkgOCBhdnJpbCAy MDA5IDE4OjEwDQo+IMOAIDogRFJBR0UsIEtlaXRoIChLZWl0aCk7IHNpcEBpZXRmLm9yZw0KPiBD YyA6IEN1bGxlbiBKZW5uaW5nczsgRWx3ZWxsLEpvaG4NCj4gT2JqZXQgOiBSZTogW1NpcF0gQ2xh cmlmaWNhdGlvbiBvbiBSRkMgNDQ1ODogU0lQIFVSSXMgZm9yICANCj4gQXBwbGljYXRpb25zIHN1 Y2hhcyBWb2ljZW1haWwgYW5kIEludGVyYWN0aXZlIFZvaWNlIFJlc3BvbnNlIChJVlIpDQo+DQo+ IEkgYmVsaWV2ZSB0aGUgaW50ZW50aW9uIHdhcyB0aGF0IHRhcmdldCB3YXMgbWFuZGF0b3J5LCBi dXQgbm90IGNhdXNlLg0KPg0KPiBJIGRvbid0IGJlbGlldmUgaGF2aW5nIGNhdXNlIGJ1dCBub3Qg dGFyZ2V0IHdvdWxkIG1ha2UgYW55IHNlbnNlLg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+IEZyb206IERSQUdFLCBLZWl0aCAoS2VpdGgpIFttYWlsdG86ZHJhZ2VAYWxjYXRl bC1sdWNlbnQuY29tXQ0KPj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwOCwgMjAwOSAwOTowNw0K Pj4gVG86IHNpcEBpZXRmLm9yZw0KPj4gQ2M6IEN1bGxlbiBKZW5uaW5nczsgQXVkZXQsIEZyYW5j b2lzIChTQzEwMDozMDU1KTsgRWx3ZWxsLCBKb2huDQo+PiBTdWJqZWN0OiBDbGFyaWZpY2F0aW9u IG9uIFJGQyA0NDU4OiBTSVAgVVJJcyBmb3IgQXBwbGljYXRpb25zIHN1Y2ggYXMNCj4+IFZvaWNl bWFpbCBhbmQgSW50ZXJhY3RpdmUgVm9pY2UgUmVzcG9uc2UgKElWUikNCj4+DQo+PiBSRkMgNDQ1 OCBkZWZpbmVzIHR3byBTSVAgVVJJIHBhcmFtZXRlcnMuDQo+Pg0KPj4gSSBjYW4gZmluZCBubyBz cGVjaWZpYyBsYW5ndWFnZSBpbiB0aGUgZG9jdW1lbnQgdGhhdCBpbmRpY2F0ZXMgIA0KPj4gd2hl dGhlcg0KPj4gdGhlc2UgdHdvIFVSSSBwYXJhbWV0ZXJzIGNhbiBiZSB1c2VkIGluZGVwZW5kZW50 bHkgb2YgZWFjaCBvdGhlciwgb3INCj4+IHdoZXRoZXIgdGhlcmUgaXMgYW4gZXhwZWN0YXRpb24g dGhhdCBib3RoIFVSSSBwYXJhbWV0ZXJzIHNob3VsZCBvbmx5DQo+PiBleGlzdCBpbiB0aGUgcHJl c2VuY2Ugb2YgZWFjaCBvdGhlci4gU3BlY2lmaWNhbGx5IGRvZXMgYW4NCj4+IGltcGxlbWVudGF0 aW9uIHRoYXQgb25seSBpbmNsdWRlcyB0aGUgImNhdXNlIiBTSVAgVVJJIHBhcmFtZXRlciBhbmQN Cj4+IG5vdCB0aGUgInRhcmdldCIgc2lwIFVSSSBwYXJhbWV0ZXIgY29uZm9ybSB0byB0aGlzIHNw ZWNpZmljYXRpb24/DQo+Pg0KPj4gQWxsIHRoZSB0ZXh0IGFuZCBleGFtcGxlcyBzZWVtIHRvIGNh cnJ5IHRoZSBpbXBsaWNhdGlvbiB0aGF0IHdoZXJlICANCj4+IG9uZQ0KPj4gZXhpc3RzLCB0aGUg b3RoZXIgb25lIHdpbGwgYWxzby4NCj4+DQo+PiBDb3VsZCBvbmUgb2YgdGhlIGF1dGhvcnMgb3Ig c29tZSBvdGhlciBpbnRlcmVzdGVkIHBhcnR5IGNsYXJpZnkgd2hhdA0KPj4gdGhleSBiZWxpZXZl IHRoZSBpbnRlbnRpb24gaXM/DQo+Pg0KPj4gcmVnYXJkcw0KPj4NCj4+IEtlaXRoDQo+Pg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTaXAgbWFp bGluZyBsaXN0ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KPiBU aGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wg VXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IA0KPiAgZm9yIHF1ZXN0aW9ucyBv biBjdXJyZW50IHNpcCBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3ICANCj4gZGV2ZWxvcG1l bnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCg== From christer.holmberg@ericsson.com Wed Apr 8 21:52:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369793A6911 for ; Wed, 8 Apr 2009 21:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.84 X-Spam-Level: X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf+O6gQaVsKA for ; Wed, 8 Apr 2009 21:52:32 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1747F3A68A5 for ; Wed, 8 Apr 2009 21:52:32 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4EBC020248; Thu, 9 Apr 2009 06:53:38 +0200 (CEST) X-AuditID: c1b4fb3e-ae023bb0000024d5-74-49dd7f52cefa Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1D1F7201E8; Thu, 9 Apr 2009 06:53:38 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 06:53:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 06:53:37 +0200 Message-ID: In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67584874B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 - comment onsection 7 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUAAGmYbAAAWaGlAADNq90A== References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> <28B7C3AA2A7ABA4A841F11217ABE78D67584874B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 09 Apr 2009 04:53:37.0968 (UTC) FILETIME=[25435300:01C9B8CF] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 - comment onsection 7 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 04:52:34 -0000 Hi,=20 >Is that a "MUST" or something that is not must like "RFC 3261 specifies when a final response is sent." RFC 3261 does specify when a final response is sent. Would you prefer something like: "The 199 Early Dialog Terminated response code does not "replace" a final response. RFC 3261 specifies when a final response is sent." Regards, Christer > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of=20 > > Christer Holmberg > > Sent: Wednesday, April 08, 2009 9:09 PM > > To: Tan, Ya Ching (NSN - DE/Munich) > > Cc: sip@ietf.org > > Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07=20 > - comment=20 > > on section 7 > >=20 > >=20 > > Hi, > >=20 > > ----- > >=20 > > >2) Section 7 Backward compatibilility > > > > > >"The 199 Early Dialog Terminated response code does not=20 > "replace" a=20 > > >final response. A final response is always sent, after one > > or many 199 > > provisional responses have been sent." > > > > > >A final response is NOT always sent. If the forking has > > resulted in at > > >least one 2xx being sent on the server transaction, no > > 3xx/4xx/5xx/6xx > > is allowed to be sent to the same > > >server transaction after the 2xx. > > > > > >So these early dialogs which receive non-2xx final response AFTER a > > first 2xx final response will not get 199 but will > > >only be considered terminated by the UAC 64*T1 seconds after the > > reception of the first 2xx response. Even those early > > >dialogs for which 199 responses have been sent (because the final > > responses were received before the first 2xx) will not > > >receive a final response. > > > > > >RFC3261/13.2.2.4: > > > > > >"The UAC core considers the INVITE transaction completed > > 64*T1 seconds > > >after the reception of the first 2xx response. At this > > point all the > > >early dialogs that have not transitioned to established=20 > dialogs are=20 > > >terminated. Once the INVITE transaction is considered > > completed by the > > >UAC core, no more new 2xx responses are expected to arrive." > > > > >=20 > > I propose the following text: > >=20 > > "The 199 Early Dialog Terminated response code does not "replace" a=20 > > final response. A final response must always be sent when=20 > mandated by=20 > > the procedures in RFC3261." > >=20 > > I think that would clarify that we are not modifying the core SIP=20 > > rules on sending final responses. > >=20 > > Regards, > >=20 > > Christer > >=20 > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 From john.elwell@siemens-enterprise.com Thu Apr 9 00:09:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070433A6BF0 for ; Thu, 9 Apr 2009 00:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kc+v9MnPkrBA for ; Thu, 9 Apr 2009 00:09:10 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 0BE4A3A6EB2 for ; Thu, 9 Apr 2009 00:09:10 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHT000AVNX4Y5@siemenscomms.co.uk> for sip@ietf.org; Thu, 09 Apr 2009 08:10:16 +0100 (BST) Date: Thu, 09 Apr 2009 08:10:14 +0100 From: "Elwell, John" In-reply-to: To: Jon Peterson , Francois Audet , Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001BEA9B6@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 07:09:11 -0000 Jon, > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Jon Peterson > Sent: 09 April 2009 03:11 > To: Francois Audet; Dean Willis > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > I think I've said in the past that the IP address and port=20 > remain relevant > because their soundness is a necessary condition for the=20 > delivery of media, > and by extension the employment of mechanisms like DTLS-SRTP.=20 > If we remove > the IP address and port from the protection domain of rendezvous layer > security entirely, then either an MITM or a cut-and-paste=20 > attacker could > exploit those SDP lines to deny service, for example, in a=20 > manner that will > not be detected by the recipient until they find their media=20 > goes AWOL. > That's basically why I think the alteration of those lines should be a > detectable condition in the rendezvous layer, and why I've=20 > argued we should > have data origin authentication for that information. That doesn't > necessarily mean we need it in the form that RFC4474=20 > currently provides it - > various sorts of patch-and-sign mechanisms would also be fine=20 > with me. But > with authentication, if media isn't reaching your=20 > interlocutor because it's > drifting out into space, at least you know who told you to=20 > aim it there - > which is, I believe, a valuable security property. [JRE] If media is encrypted, sending it to the wrong IP address/port, whilst it will cause the call to fail, will not reveal the information to the recipient. Of course, if media is not encrypted, that has worse consequences, but unencrypted media can be eavesdropped by other mechanisms, or can be spoofed or modified. Knowing who told you which IP address/port to send to only gives you a certain amount of protection. We must ensure we do not lower the security available when encryption is in use (losing the ability to authenticate the user we performed key agreement with) by clinging on to mechanisms that give some minor benefit to the unencrypted case. =20 >=20 > Most of my concerns here are really about layer violations,=20 > about how many > security functions we can defer to the media layer and how=20 > many must reside > in the rendezvous layer in order to meet our requirements.=20 > The primitives > that establish and maintain sessions, I believe, require=20 > protection in the > rendezvous layer - DTLS-SRTP isn't going to protect you=20 > against a forged > BYE, say. If the aggregate security that the system provides does not > prevent an attack that cheap, I think we've accomplished less=20 > than we can > and should. I also think that having enough credible=20 > information in a SIP > request that a recipient has reasonable grounds to authorize=20 > or reject it is > a good general design goal for our security work;=20 > provisionally accepting > requests and initiating media (DTLS-SRTP) in order to=20 > determine whether or > not the dialog is authorized protects against certain=20 > threats, but broadly I > think it doesn't address threats where an attacker/impersonator can > accomplish their goals without ever establishing a session.=20 > If we think > about, I suspect we'll find there are actually quite a few of those. [JRE] So this suggests the need for two solutions: one for protecting the rendez-vous layer and one for protecting the media layer. The problem is that the mechanism for protecting the rendez-vous layer (RFC 4474) does not work in certain deployment situations, and because we reuse that for authenticating the media layer (using it to sign the fingerprint of the certificate used at the media layer) we are unable to have protection of the media layer in those deployment situations.=20 John From ya-ching.tan@nsn.com Thu Apr 9 02:04:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4993A69B6 for ; Thu, 9 Apr 2009 02:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 iXnsDcyirox1 for ; Thu, 9 Apr 2009 02:04:28 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 16E1C3A67B1 for ; Thu, 9 Apr 2009 02:04:27 -0700 (PDT) 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 n3995WT6008268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Apr 2009 11:05:32 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3995Whx006396; Thu, 9 Apr 2009 11:05:32 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Apr 2009 11:05:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 11:05:32 +0200 Message-ID: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF090@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUAAfJ4YQ References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> From: "Tan, Ya Ching (NSN - DE/Munich)" To: "ext Christer Holmberg" X-OriginalArrivalTime: 09 Apr 2009 09:05:32.0510 (UTC) FILETIME=[563B67E0:01C9B8F2] Cc: sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 09:04:29 -0000 I would still propose to replace : "When a proxy receives a 199 response, it MUST process the response as any other non-100 provisional responses...." with=20 "When a proxy receives a 199 response on an early dialog, it MUST=20 process the response as any other non-100 provisional responses.... If a proxy receives a 199 response out of dialog, it MUST drop the=20 response." You are writing a RFC here and everything must be spelt out. This is not simply an implementation issue and it is contradictory to state on one hand that the proxy "MUST process the response as any other non-100 provisional responses", and on the other hand thinking that it is quite clear that a proxy which support 199 would not create a new dialog. Creating a new dialog is the normal behaviour of receiving a non-100 provisional response with a new To tag. A 199-unaware proxy will certainly do that. -------------- And to your reply "When the forking proxy forwards a final response it terminates all early dialogs." I do not agree that when the forking proxy forwards a final response it terminates all early dialogs, as we are talking about INVITE transaction here. RFC3261/16.7 bullet 10: If the forwarded response was a final response, the proxy MUST generate a CANCEL request for all pending client transactions associated with this response context.... The requirement to CANCEL pending client transactions upon forwarding a final response does not guarantee that an endpoint will not receive multiple 200 (OK) responses to an INVITE. 200 (OK) responses on more than one branch may be generated before the CANCEL requests can be sent and processed. and RFC3261/16.7 bullet 5: This step, combined with the next, ensures that a stateful proxy will forward exactly one final response to a non-INVITE request, and either exactly one non-2xx [final] response or one or more 2xx responses to an INVITE request. and RFC3261/13.2.2.4: The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive. The 199 mechanism will only indicate early dialogs that are terminated before the first 2xx. If the first 2xx arrives very early, immediately after many early dialogs are created, all subsequent non-2xx final=20 responses for those early dialogs cannot be conveyed to the UAC with 199. Even if the first confirmed 2xx dialog is terminated with BYE, the UAC still could expect further 2xx responses to arrive on early dialogs within 64*T1 seconds after the reception of the first 2xx response. Regards, Ya-Ching -----Original Message----- From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Wednesday, April 08, 2009 7:21 PM To: Tan, Ya Ching (NSN - DE/Munich) Cc: sip@ietf.org Subject: RE: [Sip] Draft new version: draft-ietf-sip-199-07 Hi,=20 >1) Section 6 Proxy behaviour: >=20 >"When a proxy receives a 199 response, it MUST process the response as any other non-100 provisional responses." >=20 >Do we really want this on a 199-aware proxy ? It is not stated here that the 199 response received by the proxy is only=20 >recognised if sent in an existing early dialog. If the 199 response is received by a 199-aware proxy out of any existing=20 >early dialog, should the dialog-stateful proxy create a new dialog with the new To tag and allocate resources "as any=20 >other non-100 provisional responses" ? =20 Receiving 199 out-of-dialog is an error case, and I think it's an implementation issue how those are handled. We normally don't specify that. I also think it is quite clear that a proxy which support 199 would not create a new dialog. ------ >Another condition should be added to the list of conditions that must be satisfied for the generation of the 199 by the=20 >proxy : > >- No 2xx response has been sent on the server transaction > >As 199 is meant to meet REQ 1 "to indicate to the UAC that an early dialog has been terminated BEFORE A FINAL RESPONSE is=20 >sent", and according to RFC3261/16.7 bullet 5: > > > "After a final response has been sent on the server transaction, > the following responses MUST be forwarded immediately: > > - Any 2xx response to an INVITE request > > A stateful proxy MUST NOT immediately forward any other > responses." > >199 belongs to "any other responses" which MUST not be forwarded. I guess the text you propose applies to any final response (not only 2xx) sent by the forking proxy.=20 I guess I could add some text, eventhough I think it is obvious. When the forking proxy forwards a final response it terminates all early dialogs. ----- >2) Section 7 Backward compatibilility > >"The 199 Early Dialog Terminated response code does not "replace" a final response. A final response is always sent,=20 >after one or many 199 provisional responses have been sent." > >A final response is NOT always sent. If the forking has resulted in at least one 2xx being sent on the server=20 >transaction, no 3xx/4xx/5xx/6xx is allowed to be sent to the same server transaction after the 2xx. Well, in that case a final response (the 2xx) HAS been sent. The text doesn't say that a final response must be sent on each early dialog. >So these early dialogs which receive non-2xx final response AFTER a first 2xx final response will not get 199 but will=20 >only be considered terminated by the UAC 64*T1 seconds after the reception of the first 2xx response. Even those early=20 >dialogs for which 199 responses have been sent (because the final responses were received before the first 2xx) will not=20 >receive a final response. > >RFC3261/13.2.2.4: > > "The UAC core considers the INVITE transaction completed 64*T1 seconds > after the reception of the first 2xx response. At this point all the > early dialogs that have not transitioned to established dialogs are > terminated. Once the INVITE transaction is considered completed by > the UAC core, no more new 2xx responses are expected to arrive."=20 The intention is to say that IF the server has an intention to send a final response on a specific dialog, it must not "replace" that final response with a 199. =20 ------ >3) Minor comments: > > Section 4.1 : "...When the P-Early-Media header is used..." > Add [RFC5009] after the "header". I will do that. ------ >Section 6 : "...., it generates a unique Via header branch parameter value for each fork". >Replace "fork" with "forked leg" because the term "fork" has not be defined officially or used in RFC 3261 for this=20 >purpose. I will do that. ------ >Section 6: "A forking proxy which supports generating of 199 response codes..." >Replace "codes" with "code". I would propose to say "generating of 199 responses..." instead. That is more alligned with the wording in other places of the document. ------ Thank You very much for your comments! Regards, Christer From christer.holmberg@ericsson.com Thu Apr 9 02:31:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D763A65A6 for ; Thu, 9 Apr 2009 02:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.494 X-Spam-Level: X-Spam-Status: No, score=-5.494 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDNPRsDkcD0H for ; Thu, 9 Apr 2009 02:31:04 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7CEA23A6B53 for ; Thu, 9 Apr 2009 02:30:35 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0156320549; Thu, 9 Apr 2009 11:31:42 +0200 (CEST) X-AuditID: c1b4fb3e-ac01fbb0000024d5-56-49ddc07d0364 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C44F4214CB; Thu, 9 Apr 2009 11:31:41 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 11:31:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 11:31:40 +0200 Message-ID: In-Reply-To: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF090@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUAAfJ4YQAALLzgA= References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF090@DEMUEXC014.nsn-intra.net> From: "Christer Holmberg" To: "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 09 Apr 2009 09:31:41.0606 (UTC) FILETIME=[FD7C7460:01C9B8F5] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 09:31:05 -0000 Hi,=20 >I would still propose to replace : >=20 >"When a proxy receives a 199 response, it MUST process the response as >any other non-100 provisional responses...." >=20 >with=20 >=20 >"When a proxy receives a 199 response on an early dialog, it MUST process the response as any other non-100 provisional responses.... >=20 >If a proxy receives a 199 response out of dialog, it MUST drop the response." >=20 >You are writing a RFC here and everything must be spelt out. =20 > >This is not simply an implementation issue and it is=20 >contradictory to state on one hand that the proxy "MUST=20 >process the response as any other non-100 provisional=20 >responses", and on the other hand thinking that it is quite=20 >clear that a proxy which support 199 would not create a new dialog. >Creating a new dialog is the normal behaviour of receiving a=20 >non-100 provisional response with a new To tag. A=20 >199-unaware proxy will certainly do that. I would then propose that we say that a proxy SHOULD drop unreliable 199 responses which are sent out-of-dialog.=20 If the 199 response is sent reliably, I don't think we can drop it. =20 >-------------- >=20 >And to your reply >=20 >"When the forking proxy forwards a final response it=20 >terminates all early dialogs." >=20 >I do not agree that when the forking proxy forwards a final=20 >response it terminates all early dialogs, as we are talking=20 >about INVITE transaction here. >=20 >RFC3261/16.7 bullet 10: >=20 >If the forwarded response was a final response, the=20 >proxy MUST generate a CANCEL request for all pending client transactions >associated with this response context.... >=20 >The requirement to CANCEL pending client transactions upon >forwarding a final response does not guarantee that=20 >an endpoint will not receive multiple 200 (OK) responses to an=20 >INVITE. 200 (OK) responses on more than one branch may be=20 >generated before the CANCEL requests can be sent and processed. Yes. It's a race condition. >and RFC3261/16.7 bullet 5: >=20 >This step, combined with the next, ensures that a=20 >stateful proxy will forward exactly one final response to a=20 >non-INVITE request, and either exactly one non-2xx [final] response or=20 >one or more 2xx responses to an INVITE request. >=20 >and RFC3261/13.2.2.4: >=20 >The UAC core considers the INVITE transaction completed=20 >64*T1 seconds after the reception of the first 2xx response. At this=20 >point all the early dialogs that have not transitioned to established dialogs are >terminated. Once the INVITE transaction is considered completed by >the UAC core, no more new 2xx responses are expected to arrive. Implementations will normally terminate all other early dialogs when the first 2xx is recevied. Then, if additional 2xx response (on other dialogs) are received, implementations will normally send ACK+BYE for them. So, yes, the INVITE transaction is still alive, but the early dialogs are normally terminated. >The 199 mechanism will only indicate early dialogs that are=20 >terminated before the first 2xx. If the first 2xx arrives=20 >very early, immediately after many early dialogs are created,=20 >all subsequent non-2xx final responses for those early=20 >dialogs cannot be conveyed to the UAC with 199. Even if the=20 >first confirmed 2xx dialog is terminated with BYE, the UAC=20 >still could expect further 2xx responses to arrive on early=20 >dialogs within 64*T1 seconds after the reception of the first=20 >2xx response. I doubt that a UAC implementation which recieves the first 200 OK, and then send BYE for it, will sit and wait for additional 2xx responses to arrive. The UAC will consider the call to be terminated, and free all resources for it. Otherwise, if resources are limited, the UAC may not be able to make a new call until 64*T1 seconds... Also, as the text in 16.7 says, once a final response has been forwarded, the forking proxy sends a CANCEL for all other forked legs. So, additonal 2xx responses will only reach the UAC if some an UAS sent a 2xx response before it received the CANCEL from the forking proxy. But, in any case, I can add a bullet with a condition that 199 is only sent if a final response has yet not been sent. Regards, Christer From drage@alcatel-lucent.com Thu Apr 9 02:41:07 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8616D3A6BFF for ; Thu, 9 Apr 2009 02:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.121 X-Spam-Level: X-Spam-Status: No, score=-4.121 tagged_above=-999 required=5 tests=[AWL=-1.872, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aydy9dK7WtmR for ; Thu, 9 Apr 2009 02:41:06 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id CC7BE3A6BEA for ; Thu, 9 Apr 2009 02:40:50 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n399ftCw011223 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Apr 2009 11:41:55 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 9 Apr 2009 11:41:55 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , "Tan, Ya Ching (NSN - DE/Munich)" Date: Thu, 9 Apr 2009 11:41:54 +0200 Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 - comment onsection 7 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUAAGmYbAAAWaGlAADNq90AAJhjCA Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6758487ED@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> <28B7C3AA2A7ABA4A841F11217ABE78D67584874B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: 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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "sip@ietf.org" Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 - comment onsection 7 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 09:41:07 -0000 Yep, unless there really is a new "MUST" to write in the 199 draft. regards Keith=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Thursday, April 09, 2009 5:54 AM > To: DRAGE, Keith (Keith); Tan, Ya Ching (NSN - DE/Munich) > Cc: sip@ietf.org > Subject: RE: [Sip] Draft new version: draft-ietf-sip-199-07 -=20 > comment onsection 7 >=20 >=20 > Hi,=20 >=20 > >Is that a "MUST" or something that is not must like "RFC=20 > 3261 specifies > when a final response is sent." >=20 > RFC 3261 does specify when a final response is sent. Would=20 > you prefer something like: >=20 > "The 199 Early Dialog Terminated response code does not=20 > "replace" a final response. RFC 3261 specifies when a final=20 > response is sent." >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > Christer Holmberg > > > Sent: Wednesday, April 08, 2009 9:09 PM > > > To: Tan, Ya Ching (NSN - DE/Munich) > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 > > - comment > > > on section 7 > > >=20 > > >=20 > > > Hi, > > >=20 > > > ----- > > >=20 > > > >2) Section 7 Backward compatibilility > > > > > > > >"The 199 Early Dialog Terminated response code does not > > "replace" a > > > >final response. A final response is always sent, after one > > > or many 199 > > > provisional responses have been sent." > > > > > > > >A final response is NOT always sent. If the forking has > > > resulted in at > > > >least one 2xx being sent on the server transaction, no > > > 3xx/4xx/5xx/6xx > > > is allowed to be sent to the same > > > >server transaction after the 2xx. > > > > > > > >So these early dialogs which receive non-2xx final=20 > response AFTER a > > > first 2xx final response will not get 199 but will > > > >only be considered terminated by the UAC 64*T1 seconds after the > > > reception of the first 2xx response. Even those early > > > >dialogs for which 199 responses have been sent (because the final > > > responses were received before the first 2xx) will not > > > >receive a final response. > > > > > > > >RFC3261/13.2.2.4: > > > > > > > >"The UAC core considers the INVITE transaction completed > > > 64*T1 seconds > > > >after the reception of the first 2xx response. At this > > > point all the > > > >early dialogs that have not transitioned to established > > dialogs are > > > >terminated. Once the INVITE transaction is considered > > > completed by the > > > >UAC core, no more new 2xx responses are expected to arrive." > > > > > > >=20 > > > I propose the following text: > > >=20 > > > "The 199 Early Dialog Terminated response code does not=20 > "replace" a=20 > > > final response. A final response must always be sent when > > mandated by > > > the procedures in RFC3261." > > >=20 > > > I think that would clarify that we are not modifying the core SIP=20 > > > rules on sending final responses. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > = From christer.holmberg@ericsson.com Thu Apr 9 02:47:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F49F3A6E8D for ; Thu, 9 Apr 2009 02:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.795 X-Spam-Level: X-Spam-Status: No, score=-5.795 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya7ysevB0okU for ; Thu, 9 Apr 2009 02:47:07 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9C4D53A6EB1 for ; Thu, 9 Apr 2009 02:46:49 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5600721646; Thu, 9 Apr 2009 11:47:56 +0200 (CEST) X-AuditID: c1b4fb3e-ab01dbb0000024d5-97-49ddc44c1872 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2C5BA2162A; Thu, 9 Apr 2009 11:47:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 11:47:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 11:47:55 +0200 Message-ID: In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6758487ED@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 - comment onsection 7 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUAAGmYbAAAWaGlAADNq90AAJhjCAAADMF1A= References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> <28B7C3AA2A7ABA4A841F11217ABE78D67584874B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <28B7C3AA2A7ABA4A841F11217ABE78D6758487ED@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 09 Apr 2009 09:47:55.0865 (UTC) FILETIME=[42309490:01C9B8F8] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 - comment onsection 7 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 09:47:08 -0000 =20 >Yep, unless there really is a new "MUST" to write in the 199 draft. Not in my opinion. Regards, Christer > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, April 09, 2009 5:54 AM > > To: DRAGE, Keith (Keith); Tan, Ya Ching (NSN - DE/Munich) > > Cc: sip@ietf.org > > Subject: RE: [Sip] Draft new version: draft-ietf-sip-199-07=20 > - comment=20 > > onsection 7 > >=20 > >=20 > > Hi, > >=20 > > >Is that a "MUST" or something that is not must like "RFC > > 3261 specifies > > when a final response is sent." > >=20 > > RFC 3261 does specify when a final response is sent. Would=20 > you prefer=20 > > something like: > >=20 > > "The 199 Early Dialog Terminated response code does not "replace" a=20 > > final response. RFC 3261 specifies when a final response is sent." > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of > > > > Christer Holmberg > > > > Sent: Wednesday, April 08, 2009 9:09 PM > > > > To: Tan, Ya Ching (NSN - DE/Munich) > > > > Cc: sip@ietf.org > > > > Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 > > > - comment > > > > on section 7 > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > ----- > > > >=20 > > > > >2) Section 7 Backward compatibilility > > > > > > > > > >"The 199 Early Dialog Terminated response code does not > > > "replace" a > > > > >final response. A final response is always sent, after one > > > > or many 199 > > > > provisional responses have been sent." > > > > > > > > > >A final response is NOT always sent. If the forking has > > > > resulted in at > > > > >least one 2xx being sent on the server transaction, no > > > > 3xx/4xx/5xx/6xx > > > > is allowed to be sent to the same > > > > >server transaction after the 2xx. > > > > > > > > > >So these early dialogs which receive non-2xx final > > response AFTER a > > > > first 2xx final response will not get 199 but will > > > > >only be considered terminated by the UAC 64*T1 seconds=20 > after the > > > > reception of the first 2xx response. Even those early > > > > >dialogs for which 199 responses have been sent=20 > (because the final > > > > responses were received before the first 2xx) will not > > > > >receive a final response. > > > > > > > > > >RFC3261/13.2.2.4: > > > > > > > > > >"The UAC core considers the INVITE transaction completed > > > > 64*T1 seconds > > > > >after the reception of the first 2xx response. At this > > > > point all the > > > > >early dialogs that have not transitioned to established > > > dialogs are > > > > >terminated. Once the INVITE transaction is considered > > > > completed by the > > > > >UAC core, no more new 2xx responses are expected to arrive." > > > > > > > > >=20 > > > > I propose the following text: > > > >=20 > > > > "The 199 Early Dialog Terminated response code does not > > "replace" a > > > > final response. A final response must always be sent when > > > mandated by > > > > the procedures in RFC3261." > > > >=20 > > > > I think that would clarify that we are not modifying=20 > the core SIP=20 > > > > rules on sending final responses. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > >=20 >=20 From ya-ching.tan@nsn.com Thu Apr 9 03:54:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C883A6B64 for ; Thu, 9 Apr 2009 03:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biD-3G0soPXJ for ; Thu, 9 Apr 2009 03:54:31 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id B203C3A6906 for ; Thu, 9 Apr 2009 03:54:30 -0700 (PDT) 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 n39AtZiu011570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Apr 2009 12:55:35 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n39AtWnM028420; Thu, 9 Apr 2009 12:55:35 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Apr 2009 12:55:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 12:55:34 +0200 Message-ID: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF093@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUAAfJ4YQAALLzgAAA2vzAA== References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF090@DEMUEXC014.nsn-intra.net> From: "Tan, Ya Ching (NSN - DE/Munich)" To: "ext Christer Holmberg" X-OriginalArrivalTime: 09 Apr 2009 10:55:34.0835 (UTC) FILETIME=[B5864030:01C9B901] Cc: sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 10:54:31 -0000 Comments inline start with [Tan] : -----Original Message----- From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, April 09, 2009 11:32 AM To: Tan, Ya Ching (NSN - DE/Munich) Cc: sip@ietf.org Subject: RE: [Sip] Draft new version: draft-ietf-sip-199-07 ---snip snip--- I would then propose that we say that a proxy SHOULD drop unreliable 199 responses which are sent out-of-dialog.=20 If the 199 response is sent reliably, I don't think we can drop it. [Tan] 199 response sent reliably out-of-dialog are still illegal 199. If the proxy can't drop it, does it create a new dialog with its new To tag like any non-100 responses ? Do we forward such reliable 199 responses to UAC which did not indicate support of 199 just because you think that we cannot drop reliable 1xx. If yes, such reliable but illegal 199 responses will create new early dialogs at UAC. Even if the UAC has indicated support of 199, should the reception of out-of-dialog 199 by UAC create a new early dialog ? ---snip snip--- =20 >and RFC3261/13.2.2.4: >=20 >The UAC core considers the INVITE transaction completed=20 >64*T1 seconds after the reception of the first 2xx response. At this=20 >point all the early dialogs that have not transitioned to established dialogs are >terminated. Once the INVITE transaction is considered completed by >the UAC core, no more new 2xx responses are expected to arrive. Implementations will normally terminate all other early dialogs when the first 2xx is recevied. Then, if additional 2xx response (on other dialogs) are received, implementations will normally send ACK+BYE for them. So, yes, the INVITE transaction is still alive, but the early dialogs are normally terminated. [Tan] The RFC has to be able to stand by itself and not be dependant on what implementations would normally do. Regards, Ya-Ching From drage@alcatel-lucent.com Thu Apr 9 04:04:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ADDC3A6972 for ; Thu, 9 Apr 2009 04:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZdiFKZKj6aA for ; Thu, 9 Apr 2009 04:04:15 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 6BDEB3A6B01 for ; Thu, 9 Apr 2009 04:04:14 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n39B5IxQ013256 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Apr 2009 13:05:19 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 9 Apr 2009 13:05:19 +0200 From: "DRAGE, Keith (Keith)" To: "Tan, Ya Ching (NSN - DE/Munich)" , ext Christer Holmberg Date: Thu, 9 Apr 2009 13:05:07 +0200 Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUAAfJ4YQAALLzgAAA2vzAAAAmY6w Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D675883DC3@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF090@DEMUEXC014.nsn-intra.net> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF093@DEMUEXC014.nsn-intra.net> In-Reply-To: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF093@DEMUEXC014.nsn-intra.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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "sip@ietf.org" Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 11:04:16 -0000 Tan wrote: > [Tan] The RFC has to be able to stand by itself and not be=20 > dependant on > what implementations would normally do. It is obviously impossible to implement 199 without also implementing and c= onforming to RFC 3261. If the required behaviour is already specified in RF= C 2119 language in RFC 3261, then we should not repeat that requirement in = the 199 draft.=20 Any RFC 2119 language should be limited to requirements that are changes to= RFC 3261 behaviour. regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Tan, Ya Ching (NSN - DE/Munich) > Sent: Thursday, April 09, 2009 11:56 AM > To: ext Christer Holmberg > Cc: sip@ietf.org > Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 >=20 > Comments inline start with [Tan] : >=20 > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, April 09, 2009 11:32 AM > To: Tan, Ya Ching (NSN - DE/Munich) > Cc: sip@ietf.org > Subject: RE: [Sip] Draft new version: draft-ietf-sip-199-07 >=20 >=20 > ---snip snip--- >=20 > I would then propose that we say that a proxy SHOULD drop=20 > unreliable 199 > responses which are sent out-of-dialog.=20 >=20 > If the 199 response is sent reliably, I don't think we can drop it. >=20 > [Tan] 199 response sent reliably out-of-dialog are still illegal 199. > If the proxy can't drop it, does it create a new dialog with=20 > its new To > tag like any non-100 responses ? Do we forward such reliable 199 > responses to UAC which did not indicate support of 199 just=20 > because you > think that we cannot drop reliable 1xx. If yes, such reliable but > illegal 199 responses will create new early dialogs at UAC. =20 > Even if the > UAC has indicated support of 199, should the reception of=20 > out-of-dialog > 199 by UAC create a new early dialog ? >=20 > ---snip snip--- > =20 > >and RFC3261/13.2.2.4: > >=20 > >The UAC core considers the INVITE transaction completed=20 > >64*T1 seconds after the reception of the first 2xx response.=20 > At this=20 > >point all the early dialogs that have not transitioned to established > dialogs are > >terminated. Once the INVITE transaction is considered completed by > >the UAC core, no more new 2xx responses are expected to arrive. >=20 > Implementations will normally terminate all other early=20 > dialogs when the > first 2xx is recevied. Then, if additional 2xx response (on other > dialogs) are received, implementations will normally send ACK+BYE for > them. So, yes, the INVITE transaction is still alive, but the early > dialogs are normally terminated. >=20 > [Tan] The RFC has to be able to stand by itself and not be=20 > dependant on > what implementations would normally do. >=20 >=20 > Regards, > Ya-Ching > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > = From ietf.hanserik@gmail.com Thu Apr 9 04:17:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D1228B56A for ; Thu, 9 Apr 2009 04:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.924 X-Spam-Level: X-Spam-Status: No, score=-0.924 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=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 x2CG-EsbwBL5 for ; Thu, 9 Apr 2009 04:17:08 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 791EE28C0EE for ; Thu, 9 Apr 2009 04:17:05 -0700 (PDT) Received: by ewy9 with SMTP id 9so617112ewy.37 for ; Thu, 09 Apr 2009 04:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=8s+AaU6TG3LTWcA/BmxLL2Bgup1LatHfw5yRAtVjpIA=; b=q++/zXldS+jBlaBmcB9yfKSFN2b+Y1G3e0ZjurH/Rzf5Gtfuf/4dicOfW5jVrOhkkn bd9s1zX8gSyjFdSWsYzn8K7ANeuKkA81z1/EnhwnGkteIXY7m88qngTLFmbeNo0FHrAs p5Fd05tfxN+PGRwqi2Br6unPMVwXlVKs3t4gI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qTKwX7ArRlwDZ5oVZ4y+fdOeNJbU6xeIat0fU4bLLNU5EaVx7AWFfpSqGYWKovbsrl EdcIAl35UHvG0Bjy2T1rQNs1kdLs/bI/BLELhN104OTEiHHcj83Lgty+MgNJiJ36QwMF 36EamhgKLQk+ehfoN4pxyHRwZjxCKfe21lWqI= MIME-Version: 1.0 Received: by 10.210.87.19 with SMTP id k19mr378971ebb.19.1239275892795; Thu, 09 Apr 2009 04:18:12 -0700 (PDT) Date: Thu, 9 Apr 2009 13:18:12 +0200 Message-ID: <9ae56b1e0904090418y74b7a067tb6c250277ab6d888@mail.gmail.com> From: Hans Erik van Elburg To: SIP List , Christer Holmberg Content-Type: multipart/alternative; boundary=0015174c3c605e6bb704671d6749 Subject: [Sip] draft-ietf-sip-199-07: 199 response and local ringtone generation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 11:17:09 -0000 --0015174c3c605e6bb704671d6749 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I was thinking that 199 response is also helpful for a UAC to be able to decide when local ringing tone generation can be started again, when it was suppressed before due to arriving early media which was associated with a now terminated early dialog. To highlight this I propose the following example to be added to section 4.2. Examples of policy procedures: "2. UAC ring tone generation - when a UAC receives a 180 response, it may choose to generate a local ringing tone. If early media is received, the UAC may stop the local ringback tone generation and play the incoming early media packets. If a 199 response is received on the early dialog associated with the early media, and the UAC has previously received a 180 response for another early dialog, it can start to generate local ringback tone again. Having knowledge that the early dialog associated with early media has been terminated, the UAC can also start generating local ringback tone if a 180 is received on another early dialog after the early dialog has been terminated." Best Regards, /Hans Erik van Elburg --0015174c3c605e6bb704671d6749 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I was thinking that 199 response is also helpful for a UAC to be able to de= cide when local ringing tone generation can be started again, when it was s= uppressed before due to arriving early media which was associated with a no= w terminated early dialog.

To highlight this I propose the following example to be added to sectio= n 4.2. Examples of policy procedures:
"2. UAC ring tone generation - when = a UAC receives a 180 response, it may choose to generate a local ringing to= ne. If early media is received, the UAC may stop the local ringback tone ge= neration and play the incoming early media packets. If a 199 response is re= ceived on the early dialog associated with the early media, and the UAC has= previously received a 180 response for another early dialog, it can start = to generate local ringback tone again. Having knowledge that the early dial= og associated with early media has been terminated, the UAC can also start = generating local ringback tone if a 180 is received on another early dialog= after the early dialog has been terminated."

Best Regards,
/Hans Erik van Elburg
--0015174c3c605e6bb704671d6749-- From christer.holmberg@ericsson.com Thu Apr 9 04:34:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE873A6C02 for ; Thu, 9 Apr 2009 04:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkJBWcbC7YBz for ; Thu, 9 Apr 2009 04:34:15 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 569063A6BEA for ; Thu, 9 Apr 2009 04:34:15 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 98E2B21033; Thu, 9 Apr 2009 13:35:06 +0200 (CEST) X-AuditID: c1b4fb3e-b0027bb0000024d5-5d-49dddd6a16d8 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6628221C2E; Thu, 9 Apr 2009 13:35:06 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 13:35:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 13:35:05 +0200 Message-ID: In-Reply-To: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF093@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUAAfJ4YQAALLzgAAA2vzAAABev6w References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF090@DEMUEXC014.nsn-intra.net> <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF093@DEMUEXC014.nsn-intra.net> From: "Christer Holmberg" To: "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 09 Apr 2009 11:35:06.0002 (UTC) FILETIME=[3AD99F20:01C9B907] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 11:34:16 -0000 Hi,=20 >I would then propose that we say that a proxy SHOULD drop=20 >unreliable 199 responses which are sent out-of-dialog.=20 >=20 >If the 199 response is sent reliably, I don't think we can drop it. >=20 >[Tan] 199 response sent reliably out-of-dialog are still illegal 199. >If the proxy can't drop it, does it create a new dialog with=20 >its new To tag like any non-100 responses ? Do we forward such reliable 199 >responses to UAC which did not indicate support of 199 just=20 >because you think that we cannot drop reliable 1xx. If yes, such reliable but >illegal 199 responses will create new early dialogs at UAC. =20 >Even if the UAC has indicated support of 199, should the reception of=20 >out-of-dialog 199 by UAC create a new early dialog ? Even if the proxy recieves the 199 out-if-dialog, the UAS may actually have sent it in-dialog, before the final response was sent. The 199 and the final response then "crossed each other" on the link, so that the proxy recieves the 199 before the final response. So, if the 199 is sent reliably, in-dialog, the UAS may have a state machine re-transmitting it until it receives a PRACK. Therefor I don't think the proxy can drop it. And, since other proxies upstream have already received the final response, I don't think they will reserve any resources when they receive the 199. Exactly the same thing can happen with any reliable provisional response. And, if proxies receive 199 out-of-dialog, without any associated INVITE transaction, they are not going to reserve any resources.=20 =20 >>and RFC3261/13.2.2.4: >>=20 >>The UAC core considers the INVITE transaction completed=20 >>64*T1 seconds after the reception of the first 2xx response.=20 >>At this point all the early dialogs that have not transitioned to established >>dialogs are terminated. Once the INVITE transaction is considered completed by >>the UAC core, no more new 2xx responses are expected to arrive. >=20 >Implementations will normally terminate all other early=20 >dialogs when the >first 2xx is recevied. Then, if additional 2xx response (on other >dialogs) are received, implementations will normally send ACK+BYE for >them. So, yes, the INVITE transaction is still alive, but the early >dialogs are normally terminated. >=20 >[Tan] The RFC has to be able to stand by itself and not be=20 >dependant on what implementations would normally do. Yes. I have now added some text. Regards, Christer From christer.holmberg@ericsson.com Thu Apr 9 04:38:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B7528B23E for ; Thu, 9 Apr 2009 04:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.715 X-Spam-Level: X-Spam-Status: No, score=-4.715 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG00StPuRdK2 for ; Thu, 9 Apr 2009 04:38:05 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0DE163A6AD9 for ; Thu, 9 Apr 2009 04:38:05 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 98906204EC; Thu, 9 Apr 2009 13:39:11 +0200 (CEST) X-AuditID: c1b4fb3e-ad021bb0000024d5-52-49ddde5d077c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A4BBE223E9; Thu, 9 Apr 2009 13:39:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 13:39:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B907.CA1CE2DB" Date: Thu, 9 Apr 2009 13:39:06 +0200 Message-ID: In-Reply-To: <9ae56b1e0904090418y74b7a067tb6c250277ab6d888@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-199-07: 199 response and local ringtone generation Thread-Index: Acm5BOTFvhKlPrj1QLu+ttt9HGSp/AAAs/0A References: <9ae56b1e0904090418y74b7a067tb6c250277ab6d888@mail.gmail.com> From: "Christer Holmberg" To: "Hans Erik van Elburg" , "SIP List" X-OriginalArrivalTime: 09 Apr 2009 11:39:07.0546 (UTC) FILETIME=[CAD24FA0:01C9B907] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] draft-ietf-sip-199-07: 199 response and local ringtone generation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 11:38:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B907.CA1CE2DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 I can add that example to chapter 4.2, if nobody objects. =20 Regards, =20 Christer ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: 9. huhtikuuta 2009 14:18 To: SIP List; Christer Holmberg Subject: draft-ietf-sip-199-07: 199 response and local ringtone generation =09 =09 I was thinking that 199 response is also helpful for a UAC to be able to decide when local ringing tone generation can be started again, when it was suppressed before due to arriving early media which was associated with a now terminated early dialog. =09 To highlight this I propose the following example to be added to section 4.2. Examples of policy procedures: "2. UAC ring tone generation - when a UAC receives a 180 response, it may choose to generate a local ringing tone. If early media is received, the UAC may stop the local ringback tone generation and play the incoming early media packets. If a 199 response is received on the early dialog associated with the early media, and the UAC has previously received a 180 response for another early dialog, it can start to generate local ringback tone again. Having knowledge that the early dialog associated with early media has been terminated, the UAC can also start generating local ringback tone if a 180 is received on another early dialog after the early dialog has been terminated." =09 Best Regards, /Hans Erik van Elburg =09 ------_=_NextPart_001_01C9B907.CA1CE2DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I can add = that example to=20 chapter 4.2, if nobody objects.
 
Regards,
 
Christer

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: 9. huhtikuuta 2009=20 14:18
To: SIP List; Christer Holmberg
Subject:=20 draft-ietf-sip-199-07: 199 response and local ringtone=20 generation

I was thinking that 199 response is also helpful for a UAC = to be=20 able to decide when local ringing tone generation can be started = again, when=20 it was suppressed before due to arriving early media which was = associated with=20 a now terminated early dialog.

To highlight this I propose the=20 following example to be added to section 4.2. Examples of policy=20 procedures:
"2. UAC ring tone generation - when a UAC receives a 180 response, it = may=20 choose to generate a local ringing tone. If early media is received, = the UAC=20 may stop the local ringback tone generation and play the incoming = early media=20 packets. If a 199 response is received on the early dialog associated = with the=20 early media, and the UAC has previously received a 180 response for = another=20 early dialog, it can start to generate local ringback tone again. = Having=20 knowledge that the early dialog associated with early media has been=20 terminated, the UAC can also start generating local ringback tone if a = 180 is=20 received on another early dialog after the early dialog has been=20 terminated."

Best Regards,
/Hans Erik van=20 Elburg
------_=_NextPart_001_01C9B907.CA1CE2DB-- From christer.holmberg@ericsson.com Thu Apr 9 04:45:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0D73A6906 for ; Thu, 9 Apr 2009 04:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.495 X-Spam-Level: X-Spam-Status: No, score=-5.495 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGpXtPa3QNUU for ; Thu, 9 Apr 2009 04:45:20 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 877933A6C29 for ; Thu, 9 Apr 2009 04:45:19 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E03052120F; Thu, 9 Apr 2009 13:46:25 +0200 (CEST) X-AuditID: c1b4fb3c-abee9bb000003b08-50-49dde011b093 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BBEBF206CD; Thu, 9 Apr 2009 13:46:25 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 13:46:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 13:46:24 +0200 Message-ID: In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D675883DC3@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft new version: draft-ietf-sip-199-07 Thread-Index: Acm3uGpsGfXIIruhSyKSA7SbZnx1MAAACMDwACoS2/AAAnXaUAAfJ4YQAALLzgAAA2vzAAAAmY6wAAF6HcA= References: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF08E@DEMUEXC014.nsn-intra.net><601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF090@DEMUEXC014.nsn-intra.net><601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF093@DEMUEXC014.nsn-intra.net> <28B7C3AA2A7ABA4A841F11217ABE78D675883DC3@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Tan, Ya Ching (NSN - DE/Munich)" X-OriginalArrivalTime: 09 Apr 2009 11:46:25.0325 (UTC) FILETIME=[CFC215D0:01C9B908] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 11:45:21 -0000 Hi, I think it would be enough to say: "If a proxy receives a 199 response out of dialog, it processes it as other non-100 provisional responses received out of dialog." I think the case when it will happen is really rare, so I don't see any advantage in specifying specific 199 procedures for what most likely is going to be an error case anyway. Regards, Christer > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of DRAGE, Keith (Keith) > Sent: 9. huhtikuuta 2009 14:05 > To: Tan, Ya Ching (NSN - DE/Munich); Christer Holmberg > Cc: sip@ietf.org > Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 >=20 > Tan wrote: >=20 > > [Tan] The RFC has to be able to stand by itself and not be=20 > dependant=20 > > on what implementations would normally do. >=20 > It is obviously impossible to implement 199 without also=20 > implementing and conforming to RFC 3261. If the required=20 > behaviour is already specified in RFC 2119 language in RFC=20 > 3261, then we should not repeat that requirement in the 199 draft.=20 >=20 > Any RFC 2119 language should be limited to requirements that=20 > are changes to RFC 3261 behaviour. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of=20 > > Tan, Ya Ching (NSN - DE/Munich) > > Sent: Thursday, April 09, 2009 11:56 AM > > To: ext Christer Holmberg > > Cc: sip@ietf.org > > Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 > >=20 > > Comments inline start with [Tan] : > >=20 > > -----Original Message----- > > From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, April 09, 2009 11:32 AM > > To: Tan, Ya Ching (NSN - DE/Munich) > > Cc: sip@ietf.org > > Subject: RE: [Sip] Draft new version: draft-ietf-sip-199-07 > >=20 > >=20 > > ---snip snip--- > >=20 > > I would then propose that we say that a proxy SHOULD drop=20 > unreliable=20 > > 199 responses which are sent out-of-dialog. > >=20 > > If the 199 response is sent reliably, I don't think we can drop it. > >=20 > > [Tan] 199 response sent reliably out-of-dialog are still=20 > illegal 199. > > If the proxy can't drop it, does it create a new dialog=20 > with its new=20 > > To tag like any non-100 responses ? Do we forward such reliable 199=20 > > responses to UAC which did not indicate support of 199 just because=20 > > you think that we cannot drop reliable 1xx. If yes, such=20 > reliable but=20 > > illegal 199 responses will create new early dialogs at UAC. > > Even if the > > UAC has indicated support of 199, should the reception of=20 > > out-of-dialog > > 199 by UAC create a new early dialog ? > >=20 > > ---snip snip--- > > =20 > > >and RFC3261/13.2.2.4: > > >=20 > > >The UAC core considers the INVITE transaction completed > > >64*T1 seconds after the reception of the first 2xx response.=20 > > At this > > >point all the early dialogs that have not transitioned to=20 > established > > dialogs are > > >terminated. Once the INVITE transaction is considered completed by=20 > > >the UAC core, no more new 2xx responses are expected to arrive. > >=20 > > Implementations will normally terminate all other early=20 > dialogs when=20 > > the first 2xx is recevied. Then, if additional 2xx response=20 > (on other > > dialogs) are received, implementations will normally send=20 > ACK+BYE for=20 > > them. So, yes, the INVITE transaction is still alive, but the early=20 > > dialogs are normally terminated. > >=20 > > [Tan] The RFC has to be able to stand by itself and not be=20 > dependant=20 > > on what implementations would normally do. > >=20 > >=20 > > Regards, > > Ya-Ching > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 From christer.holmberg@ericsson.com Thu Apr 9 05:26:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8629A3A6D0C for ; Thu, 9 Apr 2009 05:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.796 X-Spam-Level: X-Spam-Status: No, score=-5.796 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iAAJvqW+GUa for ; Thu, 9 Apr 2009 05:26:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 50A513A6EC8 for ; Thu, 9 Apr 2009 05:26:08 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EA76E21051 for ; Thu, 9 Apr 2009 14:27:14 +0200 (CEST) X-AuditID: c1b4fb3e-ae824bb0000024d5-00-49dde9a279b3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BE5C12119D for ; Thu, 9 Apr 2009 14:27:14 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 14:27:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B90E.831FFD19" Date: Thu, 9 Apr 2009 14:27:14 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new version: draft-ietf-sip-199-08 Thread-Index: Acm5DoNLymEfW70cQJKs+fjp+orO1g== From: "Christer Holmberg" To: X-OriginalArrivalTime: 09 Apr 2009 12:27:14.0277 (UTC) FILETIME=[83728150:01C9B90E] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] Draft new version: draft-ietf-sip-199-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 12:26:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B90E.831FFD19 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the good feedback and suggestions, I've submitted a new version (-08) of the 199 draft. It can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-08.txt Regards, Christer ------_=_NextPart_001_01C9B90E.831FFD19 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: draft-ietf-sip-199-08

Hi,

Based on the good feedback and = suggestions, I've submitted a new version (-08) of the 199 draft.

It can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-= 08.txt

Regards,

Christer

------_=_NextPart_001_01C9B90E.831FFD19-- From root@core3.amsl.com Thu Apr 9 05:30:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 697883A6EC5; Thu, 9 Apr 2009 05:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090409123001.697883A6EC5@core3.amsl.com> Date: Thu, 9 Apr 2009 05:30:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-199-08.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 12:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sip-199-08.txt Pages : 16 Date : 2009-04-09 This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and a UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-199-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-199-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-09052406.I-D@ietf.org> --NextPart-- From rjsparks@nostrum.com Thu Apr 9 08:21:17 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7323A6A4D for ; Thu, 9 Apr 2009 08:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, SPF_PASS=-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 AMK-DeuQtGsH for ; Thu, 9 Apr 2009 08:21:16 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 9A4CD3A69D0 for ; Thu, 9 Apr 2009 08:21:15 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n39FMLuI057806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Apr 2009 10:22:21 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <56CD6FEA-7CD6-4A62-A954-405F7B50D6D9@nostrum.com> From: Robert Sparks To: SIP IETF , "sip-implementors@lists.cs.columbia.edu Implementors" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 9 Apr 2009 10:22:21 -0500 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Sip] Registration for SIPIt 24 closes in 3 weeks. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 15:21:17 -0000 If you haven't already registered for SIPit 24 and plan to attend, please register today. Registration closes in 3 weeks. SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan hosted by JPNIC and NICT. Additional information is available at http://www.sipit.net and http://www.nic.ad.jp/en/sipit24/ See you in Tokyo! RjS From jon.peterson@neustar.biz Thu Apr 9 11:48:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DDD13A6B47 for ; Thu, 9 Apr 2009 11:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, 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 5Q1WMg-joyPL for ; Thu, 9 Apr 2009 11:48:53 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 076E63A6BBC for ; Thu, 9 Apr 2009 11:48:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1239302997; x=1239389397; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=HH2tE+qYqKSFpWo1ZFTTbe+6GX0gYFKfiDK2vchZI/JJpbkjK8Jw5aXpUIN8G6PlJKJyOttMii2zs4 HeYVLtcA== Received: from ([10.31.13.50]) by stihiron1.va.neustar.com with ESMTP id 5202702.16881805; Thu, 09 Apr 2009 14:49:45 -0400 Received: from 10.31.13.113 ([10.31.13.113]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Thu, 9 Apr 2009 18:49:45 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 09 Apr 2009 11:49:44 -0700 From: Jon Peterson To: "Elwell, John" , Francois Audet , Dean Willis Message-ID: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQA== In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001BEA9B6@GBNTHT12009MSX.gb002.siemens.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 18:48:54 -0000 > [JRE] If media is encrypted, sending it to the wrong IP address/port, > whilst it will cause the call to fail, will not reveal the information > to the recipient. Of course, if media is not encrypted, that has worse > consequences, but unencrypted media can be eavesdropped by other > mechanisms, or can be spoofed or modified. Knowing who told you which IP > address/port to send to only gives you a certain amount of protection. > We must ensure we do not lower the security available when encryption is > in use (losing the ability to authenticate the user we performed key > agreement with) by clinging on to mechanisms that give some minor > benefit to the unencrypted case. In fairness, I don't think the choice is between signing the IP/port and not signing the IP/port. It is between signing the entire MIME body as a blob the auth service does not have to understand, versus selecting a set of elements (understood here not to include the IP/port) and signing those exclusively. If we want to understand the benefits of the former approach, they go a bit beyond protecting the IP/port. Architecturally, signing the blob results in better future compatibility and better paths to extending SDP. If the authentication service needs to know what elements in SDP are to be included in the signature, then the authentication service behavior needs to change every time that clients start using SDP (or bodies, for that matter) in new ways. If someone wakes up tomorrow, invents a new media security model, and decides there is value in having an indicator in SDP that will let you correlate the rendezvous layer with media security keying, under the blob model that indicator can just get stuck in SDP, and the authentication service does not need to change its behavior in order to sign it. Taking this to its extreme, while I'm sure no one would stand up to defend SDPng these days, virtually everyone would say that SDP isn't the ideal tool for establishing complicated sessions; if we ever do get around to building something better, the authentication service in the blob signature model shouldn't need to understand it. This is, again, just a basic SIP layering architecture we've always followed, intended to maximize the ability of endpoints to innovate and reduce the brittleness of intermediaries. Even without looking to the future, I think there's reasonable value in signing most of the cruft in SDP. For example, as I've mentioned before, I think it's worth detecting various codec downgrade sorts of attacks. But speaking to the IP/port again specifically, I maintain that when sending media doesn't work, it is useful for UAS to ascertain who set the target IP/port, and if the IP/port shouldn't be tried anyway because they were inserted by an attacker, I think it's useful for the UAS to know that before it processes that re-INVITE, or begins altering for that initial INVITE, or what have you. >> broadly I >> think it doesn't address threats where an attacker/impersonator can >> accomplish their goals without ever establishing a session. If we think >> about, I suspect we'll find there are actually quite a few of those. > [JRE] So this suggests the need for two solutions: one for protecting > the rendez-vous layer and one for protecting the media layer. The > problem is that the mechanism for protecting the rendez-vous layer (RFC > 4474) does not work in certain deployment situations, and because we > reuse that for authenticating the media layer (using it to sign the > fingerprint of the certificate used at the media layer) we are unable to > have protection of the media layer in those deployment situations. Certainly I agree that RFC4474 interprets "certain deployment situations" as security violations, and that is a limitation of its approach. I was merely pointing out that there are also limitations to an approach where we largely defer security to the media layer; namely, it no longer protects against classes of attacks that do not intend to establish sessions as such (this discussion would come around to things like early media and forking, for example; there are also applicability concerns here with media protocols other than RTP). If these were the only two possible solutions, they we'd debate their merits and flaws, pick one, and be done. I at least haven't given up on the idea that we can draw up some other candidate solutions; the real bar to doing so seems to me to be disagreement about the problem space. So for the moment, I am still trying to talk at a pretty high level about what sorts of qualities are desirable in a solution. Jon Peterson NeuStar, Inc. > John From AUDET@nortel.com Thu Apr 9 12:09:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6123A6C78 for ; Thu, 9 Apr 2009 12:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.06 X-Spam-Level: X-Spam-Status: No, score=-6.06 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnZAzq7QqOlW for ; Thu, 9 Apr 2009 12:09:20 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2BD993A6C93 for ; Thu, 9 Apr 2009 12:09:20 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n39J9iX24737; Thu, 9 Apr 2009 19:09:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 14:09:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D5A0946@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAw References: <0D5F89FAC29E2C41B98A6A762007F5D001BEA9B6@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Jon Peterson" , "Elwell, John" , "Dean Willis" Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 19:09:21 -0000 So, at a high level, if we could "sign the blob" =E0-la-RFC 4474,=20 but exclude very specific elements (i.e., the IP:port), and combine it with DTLS-SRTP (or TLS for non-real time media), in specific=20 cases where allowing Media Relays is desireable/necessary, then we may have a solution, right? I'm interpreting your email as we should have an opt-out of integrity protection (carefully used) instead of an opt-in=20 (as per the draft-wing-identity-media draft). > -----Original Message----- > From: Jon Peterson [mailto:jon.peterson@neustar.biz]=20 > Sent: Thursday, April 09, 2009 11:50 > To: Elwell, John; Audet, Francois (SC100:3055); Dean Willis > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > > [JRE] If media is encrypted, sending it to the wrong IP=20 > address/port,=20 > > whilst it will cause the call to fail, will not reveal the=20 > information=20 > > to the recipient. Of course, if media is not encrypted,=20 > that has worse=20 > > consequences, but unencrypted media can be eavesdropped by other=20 > > mechanisms, or can be spoofed or modified. Knowing who told=20 > you which=20 > > IP address/port to send to only gives you a certain amount=20 > of protection. > > We must ensure we do not lower the security available when=20 > encryption=20 > > is in use (losing the ability to authenticate the user we performed=20 > > key agreement with) by clinging on to mechanisms that give=20 > some minor=20 > > benefit to the unencrypted case. >=20 > In fairness, I don't think the choice is between signing the=20 > IP/port and not signing the IP/port. It is between signing=20 > the entire MIME body as a blob the auth service does not have=20 > to understand, versus selecting a set of elements (understood=20 > here not to include the IP/port) and signing those=20 > exclusively. If we want to understand the benefits of the=20 > former approach, they go a bit beyond protecting the IP/port.=20 > Architecturally, signing the blob results in better future=20 > compatibility and better paths to extending SDP. If the=20 > authentication service needs to know what elements in SDP are=20 > to be included in the signature, then the authentication=20 > service behavior needs to change every time that clients=20 > start using SDP (or bodies, for that > matter) in new ways. >=20 > If someone wakes up tomorrow, invents a new media security=20 > model, and decides there is value in having an indicator in=20 > SDP that will let you correlate the rendezvous layer with=20 > media security keying, under the blob model that indicator=20 > can just get stuck in SDP, and the authentication service=20 > does not need to change its behavior in order to sign it.=20 > Taking this to its extreme, while I'm sure no one would stand=20 > up to defend SDPng these days, virtually everyone would say=20 > that SDP isn't the ideal tool for establishing complicated=20 > sessions; if we ever do get around to building something=20 > better, the authentication service in the blob signature=20 > model shouldn't need to understand it. This is, again, just a=20 > basic SIP layering architecture we've always followed,=20 > intended to maximize the ability of endpoints to innovate and=20 > reduce the brittleness of intermediaries. >=20 > Even without looking to the future, I think there's=20 > reasonable value in signing most of the cruft in SDP. For=20 > example, as I've mentioned before, I think it's worth=20 > detecting various codec downgrade sorts of attacks. But=20 > speaking to the IP/port again specifically, I maintain that=20 > when sending media doesn't work, it is useful for UAS to=20 > ascertain who set the target IP/port, and if the IP/port=20 > shouldn't be tried anyway because they were inserted by an=20 > attacker, I think it's useful for the UAS to know that before=20 > it processes that re-INVITE, or begins altering for that=20 > initial INVITE, or what have you. >=20 > >> broadly I > >> think it doesn't address threats where an=20 > attacker/impersonator can=20 > >> accomplish their goals without ever establishing a session. If we=20 > >> think about, I suspect we'll find there are actually quite=20 > a few of those. > > [JRE] So this suggests the need for two solutions: one for=20 > protecting=20 > > the rendez-vous layer and one for protecting the media layer. The=20 > > problem is that the mechanism for protecting the rendez-vous layer=20 > > (RFC > > 4474) does not work in certain deployment situations, and=20 > because we=20 > > reuse that for authenticating the media layer (using it to sign the=20 > > fingerprint of the certificate used at the media layer) we=20 > are unable=20 > > to have protection of the media layer in those deployment=20 > situations. >=20 > Certainly I agree that RFC4474 interprets "certain deployment=20 > situations" as security violations, and that is a limitation=20 > of its approach. I was merely pointing out that there are=20 > also limitations to an approach where we largely defer=20 > security to the media layer; namely, it no longer protects=20 > against classes of attacks that do not intend to establish=20 > sessions as such (this discussion would come around to things=20 > like early media and forking, for example; there are also=20 > applicability concerns here with media protocols other than=20 > RTP). If these were the only two possible solutions, they=20 > we'd debate their merits and flaws, pick one, and be done. I=20 > at least haven't given up on the idea that we can draw up=20 > some other candidate solutions; the real bar to doing so=20 > seems to me to be disagreement about the problem space. > So for the moment, I am still trying to talk at a pretty high=20 > level about what sorts of qualities are desirable in a solution. >=20 > Jon Peterson > NeuStar, Inc. >=20 > > John >=20 >=20 From john.elwell@siemens-enterprise.com Fri Apr 10 01:02:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9E13A6822 for ; Fri, 10 Apr 2009 01:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdAHXODcEbbw for ; Fri, 10 Apr 2009 01:02:35 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 8D9C03A6B6E for ; Fri, 10 Apr 2009 01:02:35 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHV00L45L246M@siemenscomms.co.uk> for sip@ietf.org; Fri, 10 Apr 2009 09:03:40 +0100 (BST) Date: Fri, 10 Apr 2009 09:03:40 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1D5A0946@zrc2hxm0.corp.nortel.com> To: Francois Audet , Jon Peterson , Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001C1EDC1@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwABrsgXA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001BEA9B6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1D5A0946@zrc2hxm0.corp.nortel.com> Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 08:02:37 -0000 Francois, Although an opt-out might be better than an opt-in, I still fear we = could end up with complex and not-forward-compatible behaviour at the = authentication service and at the verifier. So I do concur with what Jon = says. Thinking, for example, of the SDP capability negotiation mechanism = that MMUSIC is currently adding. You can have IP addresses and ports = hidden in a=3Dlines. If the opt-out mechanism wanted to opt out of = these, it would get very messy. I am more swayed by solutions whereby a copy of the original SDP is = conveyed and signed, so you can see what has been changed en route and = can decide whether to agree with the changes. A precedent already = exists. The To header field URI is a copy of the original Request-URI = (ignoring mid-dialog requests for now). RFC 4474 signs the To header = field URI (which is not expected to change) and does not sign the = Request-URI (which is expected to change). So the verifier or UAS knows = for sure where the request was originally targeted and has to use its = own judgement as to whether the changed Request-URI is reasonable or = not. John=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 09 April 2009 20:10 > To: Jon Peterson; Elwell, John; Dean Willis > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > Subject: RE: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 > So, at a high level, if we could "sign the blob" =E0-la-RFC 4474,=20 > but exclude very specific elements (i.e., the IP:port), and combine > it with DTLS-SRTP (or TLS for non-real time media), in specific=20 > cases where allowing Media Relays is desireable/necessary, then > we may have a solution, right? >=20 > I'm interpreting your email as we should have an opt-out of > integrity protection (carefully used) instead of an opt-in=20 > (as per the draft-wing-identity-media draft). >=20 >=20 >=20 > > -----Original Message----- > > From: Jon Peterson [mailto:jon.peterson@neustar.biz]=20 > > Sent: Thursday, April 09, 2009 11:50 > > To: Elwell, John; Audet, Francois (SC100:3055); Dean Willis > > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > > used in the field > >=20 > >=20 > > > [JRE] If media is encrypted, sending it to the wrong IP=20 > > address/port,=20 > > > whilst it will cause the call to fail, will not reveal the=20 > > information=20 > > > to the recipient. Of course, if media is not encrypted,=20 > > that has worse=20 > > > consequences, but unencrypted media can be eavesdropped by other=20 > > > mechanisms, or can be spoofed or modified. Knowing who told=20 > > you which=20 > > > IP address/port to send to only gives you a certain amount=20 > > of protection. > > > We must ensure we do not lower the security available when=20 > > encryption=20 > > > is in use (losing the ability to authenticate the user we=20 > performed=20 > > > key agreement with) by clinging on to mechanisms that give=20 > > some minor=20 > > > benefit to the unencrypted case. > >=20 > > In fairness, I don't think the choice is between signing the=20 > > IP/port and not signing the IP/port. It is between signing=20 > > the entire MIME body as a blob the auth service does not have=20 > > to understand, versus selecting a set of elements (understood=20 > > here not to include the IP/port) and signing those=20 > > exclusively. If we want to understand the benefits of the=20 > > former approach, they go a bit beyond protecting the IP/port.=20 > > Architecturally, signing the blob results in better future=20 > > compatibility and better paths to extending SDP. If the=20 > > authentication service needs to know what elements in SDP are=20 > > to be included in the signature, then the authentication=20 > > service behavior needs to change every time that clients=20 > > start using SDP (or bodies, for that > > matter) in new ways. > >=20 > > If someone wakes up tomorrow, invents a new media security=20 > > model, and decides there is value in having an indicator in=20 > > SDP that will let you correlate the rendezvous layer with=20 > > media security keying, under the blob model that indicator=20 > > can just get stuck in SDP, and the authentication service=20 > > does not need to change its behavior in order to sign it.=20 > > Taking this to its extreme, while I'm sure no one would stand=20 > > up to defend SDPng these days, virtually everyone would say=20 > > that SDP isn't the ideal tool for establishing complicated=20 > > sessions; if we ever do get around to building something=20 > > better, the authentication service in the blob signature=20 > > model shouldn't need to understand it. This is, again, just a=20 > > basic SIP layering architecture we've always followed,=20 > > intended to maximize the ability of endpoints to innovate and=20 > > reduce the brittleness of intermediaries. > >=20 > > Even without looking to the future, I think there's=20 > > reasonable value in signing most of the cruft in SDP. For=20 > > example, as I've mentioned before, I think it's worth=20 > > detecting various codec downgrade sorts of attacks. But=20 > > speaking to the IP/port again specifically, I maintain that=20 > > when sending media doesn't work, it is useful for UAS to=20 > > ascertain who set the target IP/port, and if the IP/port=20 > > shouldn't be tried anyway because they were inserted by an=20 > > attacker, I think it's useful for the UAS to know that before=20 > > it processes that re-INVITE, or begins altering for that=20 > > initial INVITE, or what have you. > >=20 > > >> broadly I > > >> think it doesn't address threats where an=20 > > attacker/impersonator can=20 > > >> accomplish their goals without ever establishing a=20 > session. If we=20 > > >> think about, I suspect we'll find there are actually quite=20 > > a few of those. > > > [JRE] So this suggests the need for two solutions: one for=20 > > protecting=20 > > > the rendez-vous layer and one for protecting the media layer. The=20 > > > problem is that the mechanism for protecting the=20 > rendez-vous layer=20 > > > (RFC > > > 4474) does not work in certain deployment situations, and=20 > > because we=20 > > > reuse that for authenticating the media layer (using it=20 > to sign the=20 > > > fingerprint of the certificate used at the media layer) we=20 > > are unable=20 > > > to have protection of the media layer in those deployment=20 > > situations. > >=20 > > Certainly I agree that RFC4474 interprets "certain deployment=20 > > situations" as security violations, and that is a limitation=20 > > of its approach. I was merely pointing out that there are=20 > > also limitations to an approach where we largely defer=20 > > security to the media layer; namely, it no longer protects=20 > > against classes of attacks that do not intend to establish=20 > > sessions as such (this discussion would come around to things=20 > > like early media and forking, for example; there are also=20 > > applicability concerns here with media protocols other than=20 > > RTP). If these were the only two possible solutions, they=20 > > we'd debate their merits and flaws, pick one, and be done. I=20 > > at least haven't given up on the idea that we can draw up=20 > > some other candidate solutions; the real bar to doing so=20 > > seems to me to be disagreement about the problem space. > > So for the moment, I am still trying to talk at a pretty high=20 > > level about what sorts of qualities are desirable in a solution. > >=20 > > Jon Peterson > > NeuStar, Inc. > >=20 > > > John > >=20 > >=20 >=20 From ietf.hanserik@gmail.com Fri Apr 10 01:04:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951653A6BC6 for ; Fri, 10 Apr 2009 01:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=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 YL0k9Qof4V40 for ; Fri, 10 Apr 2009 01:04:34 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 4BD873A68EA for ; Fri, 10 Apr 2009 01:04:34 -0700 (PDT) Received: by ewy9 with SMTP id 9so1040597ewy.37 for ; Fri, 10 Apr 2009 01:05:42 -0700 (PDT) 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; bh=h55lNorbfQWLV6BNVimpzhK2UyVol22s9G0XspUJaRg=; b=nxfxviItXpMNkjrJH84+fzZHKecN7VM+oSQVZnDi3k2poeeGF/wVtfgYRzExFAn/ew SB0ay2veALw5sCpIes/LGQBa8+qqI6Gnj5fUZkROJcJ7I/JjckuNyBQoJwNWnQMFEUKU +Lm3mIM9lKrencsNl/uDYre3NAewSRq+o+dPY= 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; b=P5eV3GSoPsVcf7rfKl3Rcu9FBGoXrw6SKA6+lk49zVMsiSOj72czEe5Ff74tIjX+iB mQ4bhF3IFqiRsJz4R5t1kN2l3FqC4gxT5oevsVNNeO0p+scw9Ln6LCVoiUsu/8lMApSi L3ObKT1YIRbrsts1cNB4lgPtHRtelJlOeh0bg= MIME-Version: 1.0 Received: by 10.210.144.3 with SMTP id r3mr2756132ebd.86.1239350742032; Fri, 10 Apr 2009 01:05:42 -0700 (PDT) In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6758486E4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <28B7C3AA2A7ABA4A841F11217ABE78D6758486E4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Fri, 10 Apr 2009 10:05:42 +0200 Message-ID: <9ae56b1e0904100105i351ff961wf9afac4b08938cee@mail.gmail.com> From: Hans Erik van Elburg To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=0015174be6d2bb22be04672ed402 Cc: "sip@ietf.org" , Cullen Jennings , Francois Audet , "Elwell, John" Subject: Re: [Sip] Clarification on RFC 4458: SIP URIs for Applications such as Voicemail and Interactive Voice Response (IVR) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 08:04:35 -0000 --0015174be6d2bb22be04672ed402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Specifications that only include the cause value mappings as specified in RFC4458 reuse only that part of RFC4458. Such reuse is of course fine, but carefull wording is required not to imply full conformance with RFC4458 as that would lead to the wrong implications/expectations. /Hans Erik van Elburg On Wed, Apr 8, 2009 at 6:06 PM, DRAGE, Keith (Keith) < drage@alcatel-lucent.com> wrote: > RFC 4458 defines two SIP URI parameters. > > I can find no specific language in the document that indicates whether > these two URI parameters can be used independently of each other, or whether > there is an expectation that both URI parameters should only exist in the > presence of each other. Specifically does an implementation that only > includes the "cause" SIP URI parameter and not the "target" sip URI > parameter conform to this specification? > > All the text and examples seem to carry the implication that where one > exists, the other one will also. > > Could one of the authors or some other interested party clarify what they > believe the intention is? > > regards > > Keith > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --0015174be6d2bb22be04672ed402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Specifications that only include the cause value mappings as specified in R= FC4458 reuse only that part of RFC4458.

Such reuse is of course fin= e, but carefull wording is required not to imply full conformance with RFC4= 458 as that would lead to the wrong implications/expectations.

/Hans Erik van Elburg


On Wed, Apr 8, 2009 at 6:06 PM, DRAGE, K= eith (Keith) <drage@alcatel-lucent.com> wrote:
RFC 4458 defines two SIP URI parameters.

I can find no specific language in the document that indicates whether thes= e two URI parameters can be used independently of each other, or whether th= ere is an expectation that both URI parameters should only exist in the pre= sence of each other. Specifically does an implementation that only includes= the "cause" SIP URI parameter and not the "target" sip= URI parameter conform to this specification?

All the text and examples seem to carry the implication that where one exis= ts, the other one will also.

Could one of the authors or some other interested party clarify what they b= elieve the intention is?

regards

Keith
_______________________________________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs= .columbia.edu for questions on current sip
Use sipping@ietf.org for new develo= pments on the application of sip

--0015174be6d2bb22be04672ed402-- From ietf.hanserik@gmail.com Fri Apr 10 01:35:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1D03A6D48 for ; Fri, 10 Apr 2009 01:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, HTML_MESSAGE=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 5J6t1RAw7j1e for ; Fri, 10 Apr 2009 01:35:12 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id E05DC3A6C8A for ; Fri, 10 Apr 2009 01:35:11 -0700 (PDT) Received: by ewy9 with SMTP id 9so1049873ewy.37 for ; Fri, 10 Apr 2009 01:36:19 -0700 (PDT) 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; bh=3FUvTlnNephdVqtZJI2QTOCVMLCMur1nXVd6zMCJlhY=; b=lbQXdwnFSVdZsYWR7u4jWey8PbQ/lSBJs4qecxA1vFphjJoKzhq1XonEsO7XOBpO6r xsjhYE2FC4iyWGD8hzQR6nHosgJIHh2UG28zshGvuylboNR84j3tnRvM/JFZycY5Lge5 Pg4yWC6nGwrZL4UfG7NRXeauST/3Z2D3BJWm8= 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; b=Fm80INEHLbjTRTM1lGvGXBVE8YtIay0oKzItE+LaKKMMU3TuFHzpdAkrBExVroZoW5 uAULBkoyd863GKgzOnxP8CbOXEt7ge4eFAQDccLeXfFrkoZgy89IRdtlMD2Ded2bfdpa ku7fil7RchiPC2Bz8g2sYDEBPXJ9LhLcQRtAI= MIME-Version: 1.0 Received: by 10.210.18.8 with SMTP id 8mr1398821ebr.51.1239352579234; Fri, 10 Apr 2009 01:36:19 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001C1EDC1@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D001BEA9B6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1D5A0946@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D001C1EDC1@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 10 Apr 2009 10:36:19 +0200 Message-ID: <9ae56b1e0904100136n4820db6dud334333a15ffeef7@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=0015174c43d83c9b4e04672f4207 Cc: Cullen Jennings , Jon Peterson , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 08:35:13 -0000 --0015174c43d83c9b4e04672f4207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit But the UAS will mostly receive its own contact address in the Request-URI, so there is not much to judge there. /Hans Erik van Elburg On Fri, Apr 10, 2009 at 10:03 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > So the verifier or UAS knows for sure where the request was originally > targeted and has to use its own judgement as to whether the changed > Request-URI is reasonable or not. > --0015174c43d83c9b4e04672f4207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable But the UAS will mostly receive its own contact address in the Request-URI,= so there is not much to judge there.

/Hans Erik van = Elburg


On Fri, Apr 10, 2009 at 10:03 AM, Elwell= , John <john.elwell@siemens-enterprise.com> wrote:
So the verifier or UAS knows for sure wher= e the request was originally targeted and has to use its own judgement as t= o whether the changed Request-URI is reasonable or not.
<= /div>
--0015174c43d83c9b4e04672f4207-- From AUDET@nortel.com Fri Apr 10 08:25:33 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F096D3A6EE4 for ; Fri, 10 Apr 2009 08:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTuWW4yYNOpg for ; Fri, 10 Apr 2009 08:25:31 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 776A43A6EE5 for ; Fri, 10 Apr 2009 08:25:31 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3AFQYE17069; Fri, 10 Apr 2009 15:26:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Apr 2009 10:25:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D5F2776@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D001C1EDC1@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwABrsgXAAD2PcQA== References: <0D5F89FAC29E2C41B98A6A762007F5D001BEA9B6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1D5A0946@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D001C1EDC1@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Jon Peterson" , "Dean Willis" Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 15:25:33 -0000 But.... This is unlikely to be backward-compatible, no? Are you saying that the receiver of the INVITE would get a multipart MIME, one of them signed with RFC 4474, and the other with something else? What I had in mind for "opt-out" was that the signature would avoid all instances of it's own IP address and port. But yeah, you are right, this is non-trivial and error-prone. Using TURN is looking more and more attractive... > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Friday, April 10, 2009 01:04 > To: Audet, Francois (SC100:3055); Jon Peterson; Dean Willis > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > Subject: RE: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 > Francois, >=20 > Although an opt-out might be better than an opt-in, I still=20 > fear we could end up with complex and not-forward-compatible=20 > behaviour at the authentication service and at the verifier.=20 > So I do concur with what Jon says. Thinking, for example, of=20 > the SDP capability negotiation mechanism that MMUSIC is=20 > currently adding. You can have IP addresses and ports hidden=20 > in a=3Dlines. If the opt-out mechanism wanted to opt out of=20 > these, it would get very messy. >=20 > I am more swayed by solutions whereby a copy of the original=20 > SDP is conveyed and signed, so you can see what has been=20 > changed en route and can decide whether to agree with the=20 > changes. A precedent already exists. The To header field URI=20 > is a copy of the original Request-URI (ignoring mid-dialog=20 > requests for now). RFC 4474 signs the To header field URI=20 > (which is not expected to change) and does not sign the=20 > Request-URI (which is expected to change). So the verifier or=20 > UAS knows for sure where the request was originally targeted=20 > and has to use its own judgement as to whether the changed=20 > Request-URI is reasonable or not. >=20 > John=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 09 April 2009 20:10 > > To: Jon Peterson; Elwell, John; Dean Willis > > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > > Subject: RE: [Sip] francois' comments and why RFC4474 not=20 > used in the=20 > > field > >=20 > > So, at a high level, if we could "sign the blob" =E0-la-RFC 4474, = but=20 > > exclude very specific elements (i.e., the IP:port), and combine it=20 > > with DTLS-SRTP (or TLS for non-real time media), in specific cases=20 > > where allowing Media Relays is desireable/necessary, then=20 > we may have=20 > > a solution, right? > >=20 > > I'm interpreting your email as we should have an opt-out of=20 > integrity=20 > > protection (carefully used) instead of an opt-in (as per the=20 > > draft-wing-identity-media draft). > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Jon Peterson [mailto:jon.peterson@neustar.biz] > > > Sent: Thursday, April 09, 2009 11:50 > > > To: Elwell, John; Audet, Francois (SC100:3055); Dean Willis > > > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > > > Subject: Re: [Sip] francois' comments and why RFC4474 not used in=20 > > > the field > > >=20 > > >=20 > > > > [JRE] If media is encrypted, sending it to the wrong IP > > > address/port, > > > > whilst it will cause the call to fail, will not reveal the > > > information > > > > to the recipient. Of course, if media is not encrypted, > > > that has worse > > > > consequences, but unencrypted media can be eavesdropped=20 > by other=20 > > > > mechanisms, or can be spoofed or modified. Knowing who told > > > you which > > > > IP address/port to send to only gives you a certain amount > > > of protection. > > > > We must ensure we do not lower the security available when > > > encryption > > > > is in use (losing the ability to authenticate the user we > > performed > > > > key agreement with) by clinging on to mechanisms that give > > > some minor > > > > benefit to the unencrypted case. > > >=20 > > > In fairness, I don't think the choice is between signing=20 > the IP/port=20 > > > and not signing the IP/port. It is between signing the=20 > entire MIME=20 > > > body as a blob the auth service does not have to=20 > understand, versus=20 > > > selecting a set of elements (understood here not to include the=20 > > > IP/port) and signing those exclusively. If we want to=20 > understand the=20 > > > benefits of the former approach, they go a bit beyond=20 > protecting the=20 > > > IP/port. > > > Architecturally, signing the blob results in better future=20 > > > compatibility and better paths to extending SDP. If the=20 > > > authentication service needs to know what elements in SDP=20 > are to be=20 > > > included in the signature, then the authentication=20 > service behavior=20 > > > needs to change every time that clients start using SDP=20 > (or bodies,=20 > > > for that > > > matter) in new ways. > > >=20 > > > If someone wakes up tomorrow, invents a new media security model,=20 > > > and decides there is value in having an indicator in SDP=20 > that will=20 > > > let you correlate the rendezvous layer with media=20 > security keying,=20 > > > under the blob model that indicator can just get stuck in=20 > SDP, and=20 > > > the authentication service does not need to change its=20 > behavior in=20 > > > order to sign it. > > > Taking this to its extreme, while I'm sure no one would=20 > stand up to=20 > > > defend SDPng these days, virtually everyone would say=20 > that SDP isn't=20 > > > the ideal tool for establishing complicated sessions; if=20 > we ever do=20 > > > get around to building something better, the=20 > authentication service=20 > > > in the blob signature model shouldn't need to understand it. This=20 > > > is, again, just a basic SIP layering architecture we've always=20 > > > followed, intended to maximize the ability of endpoints=20 > to innovate=20 > > > and reduce the brittleness of intermediaries. > > >=20 > > > Even without looking to the future, I think there's=20 > reasonable value=20 > > > in signing most of the cruft in SDP. For example, as I've=20 > mentioned=20 > > > before, I think it's worth detecting various codec=20 > downgrade sorts=20 > > > of attacks. But speaking to the IP/port again specifically, I=20 > > > maintain that when sending media doesn't work, it is=20 > useful for UAS=20 > > > to ascertain who set the target IP/port, and if the IP/port=20 > > > shouldn't be tried anyway because they were inserted by=20 > an attacker,=20 > > > I think it's useful for the UAS to know that before it processes=20 > > > that re-INVITE, or begins altering for that initial=20 > INVITE, or what=20 > > > have you. > > >=20 > > > >> broadly I > > > >> think it doesn't address threats where an > > > attacker/impersonator can > > > >> accomplish their goals without ever establishing a > > session. If we > > > >> think about, I suspect we'll find there are actually quite > > > a few of those. > > > > [JRE] So this suggests the need for two solutions: one for > > > protecting > > > > the rendez-vous layer and one for protecting the media=20 > layer. The=20 > > > > problem is that the mechanism for protecting the > > rendez-vous layer > > > > (RFC > > > > 4474) does not work in certain deployment situations, and > > > because we > > > > reuse that for authenticating the media layer (using it > > to sign the > > > > fingerprint of the certificate used at the media layer) we > > > are unable > > > > to have protection of the media layer in those deployment > > > situations. > > >=20 > > > Certainly I agree that RFC4474 interprets "certain deployment=20 > > > situations" as security violations, and that is a=20 > limitation of its=20 > > > approach. I was merely pointing out that there are also=20 > limitations=20 > > > to an approach where we largely defer security to the=20 > media layer;=20 > > > namely, it no longer protects against classes of attacks=20 > that do not=20 > > > intend to establish sessions as such (this discussion would come=20 > > > around to things like early media and forking, for example; there=20 > > > are also applicability concerns here with media protocols=20 > other than=20 > > > RTP). If these were the only two possible solutions, they we'd=20 > > > debate their merits and flaws, pick one, and be done. I at least=20 > > > haven't given up on the idea that we can draw up some other=20 > > > candidate solutions; the real bar to doing so seems to me to be=20 > > > disagreement about the problem space. > > > So for the moment, I am still trying to talk at a pretty=20 > high level=20 > > > about what sorts of qualities are desirable in a solution. > > >=20 > > > Jon Peterson > > > NeuStar, Inc. > > >=20 > > > > John > > >=20 > > >=20 > >=20 >=20 From jon.peterson@neustar.biz Fri Apr 10 09:08:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9753A6928 for ; Fri, 10 Apr 2009 09:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M-gwaIFyTaj for ; Fri, 10 Apr 2009 09:08:39 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id A59BF3A67F5 for ; Fri, 10 Apr 2009 09:08:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1239379786; x=1239466186; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=T8X0FicIirFK1znZNc9V5WCDEJYyNK1ouIj8S/8zUvx6dnXo99rfCzocfDhbAYMyzN+bNrc58umE+G Q5f3Lw+w== Received: from ([10.31.13.50]) by stihiron1.va.neustar.com with ESMTP id 5202702.16906768; Fri, 10 Apr 2009 12:09:39 -0400 Received: from 10.31.13.108 ([10.31.13.108]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Apr 2009 16:09:39 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 10 Apr 2009 09:09:38 -0700 From: Jon Peterson To: Francois Audet , "Elwell, John" , Dean Willis Message-ID: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5s= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D5A0946@zrc2hxm0.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 16:08:40 -0000 At a high level, when an intermediary is going to relay your media, the intermediary (not the UAC) is the source of the IP/port data that appears i= n SDP, and as such, I can accept alternatives to securing that data with a signature from the originating administrative domain (abstractly, that goes equally for SBCs and TURN, I suppose). I don't however believe it follows from this that it just doesn't matter at all who sets the IP/port data in SDP. I think it does matter, and it matters most when we consider approache= s that defer security checks from the SIP layer to the media layer. For example, if relatively weak SIP-layer security facilitates cut-and-paste attacks, then an eavesdropper could listen to INVITEs, forge re-INVITEs wit= h the same signature but set the IP/port to something unhelpful, and methodically tear down a target's calls five seconds after they start. So from my perspective, verifying the origin of IP/port data still has value, even if the origin of that data is not the originating administrative domain. Jon Peterson NeuStar, Inc. On 4/9/09 12:09 PM, "Francois Audet" wrote: > So, at a high level, if we could "sign the blob" =E0-la-RFC 4474, > but exclude very specific elements (i.e., the IP:port), and combine > it with DTLS-SRTP (or TLS for non-real time media), in specific > cases where allowing Media Relays is desireable/necessary, then > we may have a solution, right? >=20 > I'm interpreting your email as we should have an opt-out of > integrity protection (carefully used) instead of an opt-in > (as per the draft-wing-identity-media draft). >=20 >=20 >=20 >> -----Original Message----- >> From: Jon Peterson [mailto:jon.peterson@neustar.biz] >> Sent: Thursday, April 09, 2009 11:50 >> To: Elwell, John; Audet, Francois (SC100:3055); Dean Willis >> Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) >> Subject: Re: [Sip] francois' comments and why RFC4474 not >> used in the field >>=20 >>=20 >>> [JRE] If media is encrypted, sending it to the wrong IP >> address/port,=20 >>> whilst it will cause the call to fail, will not reveal the >> information=20 >>> to the recipient. Of course, if media is not encrypted, >> that has worse=20 >>> consequences, but unencrypted media can be eavesdropped by other >>> mechanisms, or can be spoofed or modified. Knowing who told >> you which=20 >>> IP address/port to send to only gives you a certain amount >> of protection. >>> We must ensure we do not lower the security available when >> encryption=20 >>> is in use (losing the ability to authenticate the user we performed >>> key agreement with) by clinging on to mechanisms that give >> some minor=20 >>> benefit to the unencrypted case. >>=20 >> In fairness, I don't think the choice is between signing the >> IP/port and not signing the IP/port. It is between signing >> the entire MIME body as a blob the auth service does not have >> to understand, versus selecting a set of elements (understood >> here not to include the IP/port) and signing those >> exclusively. If we want to understand the benefits of the >> former approach, they go a bit beyond protecting the IP/port. >> Architecturally, signing the blob results in better future >> compatibility and better paths to extending SDP. If the >> authentication service needs to know what elements in SDP are >> to be included in the signature, then the authentication >> service behavior needs to change every time that clients >> start using SDP (or bodies, for that >> matter) in new ways. >>=20 >> If someone wakes up tomorrow, invents a new media security >> model, and decides there is value in having an indicator in >> SDP that will let you correlate the rendezvous layer with >> media security keying, under the blob model that indicator >> can just get stuck in SDP, and the authentication service >> does not need to change its behavior in order to sign it. >> Taking this to its extreme, while I'm sure no one would stand >> up to defend SDPng these days, virtually everyone would say >> that SDP isn't the ideal tool for establishing complicated >> sessions; if we ever do get around to building something >> better, the authentication service in the blob signature >> model shouldn't need to understand it. This is, again, just a >> basic SIP layering architecture we've always followed, >> intended to maximize the ability of endpoints to innovate and >> reduce the brittleness of intermediaries. >>=20 >> Even without looking to the future, I think there's >> reasonable value in signing most of the cruft in SDP. For >> example, as I've mentioned before, I think it's worth >> detecting various codec downgrade sorts of attacks. But >> speaking to the IP/port again specifically, I maintain that >> when sending media doesn't work, it is useful for UAS to >> ascertain who set the target IP/port, and if the IP/port >> shouldn't be tried anyway because they were inserted by an >> attacker, I think it's useful for the UAS to know that before >> it processes that re-INVITE, or begins altering for that >> initial INVITE, or what have you. >>=20 >>>> broadly I >>>> think it doesn't address threats where an >> attacker/impersonator can >>>> accomplish their goals without ever establishing a session. If we >>>> think about, I suspect we'll find there are actually quite >> a few of those. >>> [JRE] So this suggests the need for two solutions: one for >> protecting=20 >>> the rendez-vous layer and one for protecting the media layer. The >>> problem is that the mechanism for protecting the rendez-vous layer >>> (RFC >>> 4474) does not work in certain deployment situations, and >> because we=20 >>> reuse that for authenticating the media layer (using it to sign the >>> fingerprint of the certificate used at the media layer) we >> are unable=20 >>> to have protection of the media layer in those deployment >> situations. >>=20 >> Certainly I agree that RFC4474 interprets "certain deployment >> situations" as security violations, and that is a limitation >> of its approach. I was merely pointing out that there are >> also limitations to an approach where we largely defer >> security to the media layer; namely, it no longer protects >> against classes of attacks that do not intend to establish >> sessions as such (this discussion would come around to things >> like early media and forking, for example; there are also >> applicability concerns here with media protocols other than >> RTP). If these were the only two possible solutions, they >> we'd debate their merits and flaws, pick one, and be done. I >> at least haven't given up on the idea that we can draw up >> some other candidate solutions; the real bar to doing so >> seems to me to be disagreement about the problem space. >> So for the moment, I am still trying to talk at a pretty high >> level about what sorts of qualities are desirable in a solution. >>=20 >> Jon Peterson >> NeuStar, Inc. >>=20 >>> John >>=20 >>=20 From AUDET@nortel.com Fri Apr 10 11:37:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76A43A6DDB for ; Fri, 10 Apr 2009 11:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0zkCuxzOHDw for ; Fri, 10 Apr 2009 11:37:03 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 858023A6A68 for ; Fri, 10 Apr 2009 11:37:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3AIb3b06859; Fri, 10 Apr 2009 18:37:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Apr 2009 13:37:22 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D5F2B8B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sABO07UA== References: <1ECE0EB50388174790F9694F77522CCF1D5A0946@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Jon Peterson" , "Elwell, John" , "Dean Willis" Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 18:37:05 -0000 Yes, this makes sense to me. The attack is not impersonnation, it's interuption of media. Verifying the address of the relay seems difficult to me. It could be in source domain, destination domain, some intermediary. Or there could even be more than one. Unless we do it hop by hop. I guess we could have another layer of TLS exchange between the UA and the intermediary (where instead of a self-signed cert,=20 you would actually autenticate your intermediary). Wouldn't do wonders for backward compatibility however, and I'm not sure it would be simpler than TURN. > -----Original Message----- > From: Jon Peterson [mailto:jon.peterson@neustar.biz]=20 > Sent: Friday, April 10, 2009 09:10 > To: Audet, Francois (SC100:3055); Elwell, John; Dean Willis > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > At a high level, when an intermediary is going to relay your=20 > media, the intermediary (not the UAC) is the source of the=20 > IP/port data that appears in SDP, and as such, I can accept=20 > alternatives to securing that data with a signature from the=20 > originating administrative domain (abstractly, that goes=20 > equally for SBCs and TURN, I suppose). I don't however=20 > believe it follows from this that it just doesn't matter at=20 > all who sets the IP/port data in SDP. I think it does matter,=20 > and it matters most when we consider approaches that defer=20 > security checks from the SIP layer to the media layer. For=20 > example, if relatively weak SIP-layer security facilitates=20 > cut-and-paste attacks, then an eavesdropper could listen to=20 > INVITEs, forge re-INVITEs with the same signature but set the=20 > IP/port to something unhelpful, and methodically tear down a=20 > target's calls five seconds after they start. So from my=20 > perspective, verifying the origin of IP/port data still has=20 > value, even if the origin of that data is not the originating=20 > administrative domain. >=20 > Jon Peterson > NeuStar, Inc. >=20 >=20 > On 4/9/09 12:09 PM, "Francois Audet" wrote: >=20 > > So, at a high level, if we could "sign the blob" =E0-la-RFC 4474, = but=20 > > exclude very specific elements (i.e., the IP:port), and combine it=20 > > with DTLS-SRTP (or TLS for non-real time media), in specific cases=20 > > where allowing Media Relays is desireable/necessary, then=20 > we may have=20 > > a solution, right? > >=20 > > I'm interpreting your email as we should have an opt-out of=20 > integrity=20 > > protection (carefully used) instead of an opt-in (as per the=20 > > draft-wing-identity-media draft). > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Jon Peterson [mailto:jon.peterson@neustar.biz] > >> Sent: Thursday, April 09, 2009 11:50 > >> To: Elwell, John; Audet, Francois (SC100:3055); Dean Willis > >> Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > >> Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the=20 > >> field > >>=20 > >>=20 > >>> [JRE] If media is encrypted, sending it to the wrong IP > >> address/port, > >>> whilst it will cause the call to fail, will not reveal the > >> information > >>> to the recipient. Of course, if media is not encrypted, > >> that has worse > >>> consequences, but unencrypted media can be eavesdropped by other=20 > >>> mechanisms, or can be spoofed or modified. Knowing who told > >> you which > >>> IP address/port to send to only gives you a certain amount > >> of protection. > >>> We must ensure we do not lower the security available when > >> encryption > >>> is in use (losing the ability to authenticate the user we=20 > performed=20 > >>> key agreement with) by clinging on to mechanisms that give > >> some minor > >>> benefit to the unencrypted case. > >>=20 > >> In fairness, I don't think the choice is between signing=20 > the IP/port=20 > >> and not signing the IP/port. It is between signing the entire MIME=20 > >> body as a blob the auth service does not have to=20 > understand, versus=20 > >> selecting a set of elements (understood here not to include the=20 > >> IP/port) and signing those exclusively. If we want to=20 > understand the=20 > >> benefits of the former approach, they go a bit beyond=20 > protecting the=20 > >> IP/port. > >> Architecturally, signing the blob results in better future=20 > >> compatibility and better paths to extending SDP. If the=20 > >> authentication service needs to know what elements in SDP=20 > are to be=20 > >> included in the signature, then the authentication service=20 > behavior=20 > >> needs to change every time that clients start using SDP=20 > (or bodies,=20 > >> for that > >> matter) in new ways. > >>=20 > >> If someone wakes up tomorrow, invents a new media security=20 > model, and=20 > >> decides there is value in having an indicator in SDP that will let=20 > >> you correlate the rendezvous layer with media security=20 > keying, under=20 > >> the blob model that indicator can just get stuck in SDP, and the=20 > >> authentication service does not need to change its=20 > behavior in order=20 > >> to sign it. > >> Taking this to its extreme, while I'm sure no one would=20 > stand up to=20 > >> defend SDPng these days, virtually everyone would say that=20 > SDP isn't=20 > >> the ideal tool for establishing complicated sessions; if=20 > we ever do=20 > >> get around to building something better, the=20 > authentication service=20 > >> in the blob signature model shouldn't need to understand=20 > it. This is,=20 > >> again, just a basic SIP layering architecture we've always=20 > followed,=20 > >> intended to maximize the ability of endpoints to innovate=20 > and reduce=20 > >> the brittleness of intermediaries. > >>=20 > >> Even without looking to the future, I think there's=20 > reasonable value=20 > >> in signing most of the cruft in SDP. For example, as I've=20 > mentioned=20 > >> before, I think it's worth detecting various codec=20 > downgrade sorts of=20 > >> attacks. But speaking to the IP/port again specifically, I=20 > maintain=20 > >> that when sending media doesn't work, it is useful for UAS to=20 > >> ascertain who set the target IP/port, and if the IP/port=20 > shouldn't be=20 > >> tried anyway because they were inserted by an attacker, I=20 > think it's=20 > >> useful for the UAS to know that before it processes that=20 > re-INVITE,=20 > >> or begins altering for that initial INVITE, or what have you. > >>=20 > >>>> broadly I > >>>> think it doesn't address threats where an > >> attacker/impersonator can > >>>> accomplish their goals without ever establishing a=20 > session. If we=20 > >>>> think about, I suspect we'll find there are actually quite > >> a few of those. > >>> [JRE] So this suggests the need for two solutions: one for > >> protecting > >>> the rendez-vous layer and one for protecting the media layer. The=20 > >>> problem is that the mechanism for protecting the=20 > rendez-vous layer=20 > >>> (RFC > >>> 4474) does not work in certain deployment situations, and > >> because we > >>> reuse that for authenticating the media layer (using it=20 > to sign the=20 > >>> fingerprint of the certificate used at the media layer) we > >> are unable > >>> to have protection of the media layer in those deployment > >> situations. > >>=20 > >> Certainly I agree that RFC4474 interprets "certain deployment=20 > >> situations" as security violations, and that is a=20 > limitation of its=20 > >> approach. I was merely pointing out that there are also=20 > limitations=20 > >> to an approach where we largely defer security to the media layer;=20 > >> namely, it no longer protects against classes of attacks=20 > that do not=20 > >> intend to establish sessions as such (this discussion would come=20 > >> around to things like early media and forking, for=20 > example; there are=20 > >> also applicability concerns here with media protocols other than=20 > >> RTP). If these were the only two possible solutions, they=20 > we'd debate=20 > >> their merits and flaws, pick one, and be done. I at least haven't=20 > >> given up on the idea that we can draw up some other candidate=20 > >> solutions; the real bar to doing so seems to me to be disagreement=20 > >> about the problem space. > >> So for the moment, I am still trying to talk at a pretty=20 > high level=20 > >> about what sorts of qualities are desirable in a solution. > >>=20 > >> Jon Peterson > >> NeuStar, Inc. > >>=20 > >>> John > >>=20 > >>=20 >=20 >=20 From jon.peterson@neustar.biz Fri Apr 10 12:27:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF2A3A6BAC for ; Fri, 10 Apr 2009 12:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktufdlxD2bVF for ; Fri, 10 Apr 2009 12:27:30 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id BFE243A6A06 for ; Fri, 10 Apr 2009 12:27:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1239391715; x=1239478115; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=mBVvHvD6vvbeXub6bfrCaKgK7a2UPKL4EWNosSdT7YqXsVCdEH1oTwTUvLufC0+BJztACsSVFUzFlG DZV6mhtg== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.17366558; Fri, 10 Apr 2009 15:28:20 -0400 Received: from 10.31.13.108 ([10.31.13.108]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Apr 2009 19:28:20 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 10 Apr 2009 12:28:19 -0700 From: Jon Peterson To: Francois Audet , "Elwell, John" , Dean Willis Message-ID: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sABO07UAACAyOl In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D5F2B8B@zrc2hxm0.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 19:27:31 -0000 If I may quibble here: > The attack is not impersonation, it's interruption of media. The attack relies on impersonation to accomplish interruption of media. The attacker listens to Alice's INVITE, and then sends a cut-and-pasted re-INVITE saying "This is Alice again, would you mind sending my media here instead please." Impersonation is almost always a tool that attackers use t= o accomplish some particular goal, even if it's just tricking you into accepting unwanted communications. I'm not sure I'd say impersonation is an attack as such, but by preventing it, we prevent whole categories of attack= s and grant ourselves more powers in crafting authorization policies. Jon Peterson NeuStar, Inc. On 4/10/09 11:37 AM, "Francois Audet" wrote: > Yes, this makes sense to me. >=20 > The attack is not impersonnation, it's interuption of media. >=20 > Verifying the address of the relay seems difficult to me. It could > be in source domain, destination domain, some intermediary. Or there > could even be more than one. Unless we do it hop by hop. >=20 > I guess we could have another layer of TLS exchange between the > UA and the intermediary (where instead of a self-signed cert, > you would actually autenticate your intermediary). Wouldn't do > wonders for backward compatibility however, and I'm not sure > it would be simpler than TURN. >=20 >> -----Original Message----- >> From: Jon Peterson [mailto:jon.peterson@neustar.biz] >> Sent: Friday, April 10, 2009 09:10 >> To: Audet, Francois (SC100:3055); Elwell, John; Dean Willis >> Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) >> Subject: Re: [Sip] francois' comments and why RFC4474 not >> used in the field >>=20 >>=20 >> At a high level, when an intermediary is going to relay your >> media, the intermediary (not the UAC) is the source of the >> IP/port data that appears in SDP, and as such, I can accept >> alternatives to securing that data with a signature from the >> originating administrative domain (abstractly, that goes >> equally for SBCs and TURN, I suppose). I don't however >> believe it follows from this that it just doesn't matter at >> all who sets the IP/port data in SDP. I think it does matter, >> and it matters most when we consider approaches that defer >> security checks from the SIP layer to the media layer. For >> example, if relatively weak SIP-layer security facilitates >> cut-and-paste attacks, then an eavesdropper could listen to >> INVITEs, forge re-INVITEs with the same signature but set the >> IP/port to something unhelpful, and methodically tear down a >> target's calls five seconds after they start. So from my >> perspective, verifying the origin of IP/port data still has >> value, even if the origin of that data is not the originating >> administrative domain. >>=20 >> Jon Peterson >> NeuStar, Inc. >>=20 >>=20 >> On 4/9/09 12:09 PM, "Francois Audet" wrote: >>=20 >>> So, at a high level, if we could "sign the blob" =E0-la-RFC 4474, but >>> exclude very specific elements (i.e., the IP:port), and combine it >>> with DTLS-SRTP (or TLS for non-real time media), in specific cases >>> where allowing Media Relays is desireable/necessary, then >> we may have=20 >>> a solution, right? >>>=20 >>> I'm interpreting your email as we should have an opt-out of >> integrity=20 >>> protection (carefully used) instead of an opt-in (as per the >>> draft-wing-identity-media draft). >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Jon Peterson [mailto:jon.peterson@neustar.biz] >>>> Sent: Thursday, April 09, 2009 11:50 >>>> To: Elwell, John; Audet, Francois (SC100:3055); Dean Willis >>>> Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) >>>> Subject: Re: [Sip] francois' comments and why RFC4474 not >> used in the=20 >>>> field >>>>=20 >>>>=20 >>>>> [JRE] If media is encrypted, sending it to the wrong IP >>>> address/port, >>>>> whilst it will cause the call to fail, will not reveal the >>>> information >>>>> to the recipient. Of course, if media is not encrypted, >>>> that has worse >>>>> consequences, but unencrypted media can be eavesdropped by other >>>>> mechanisms, or can be spoofed or modified. Knowing who told >>>> you which >>>>> IP address/port to send to only gives you a certain amount >>>> of protection. >>>>> We must ensure we do not lower the security available when >>>> encryption >>>>> is in use (losing the ability to authenticate the user we >> performed=20 >>>>> key agreement with) by clinging on to mechanisms that give >>>> some minor >>>>> benefit to the unencrypted case. >>>>=20 >>>> In fairness, I don't think the choice is between signing >> the IP/port=20 >>>> and not signing the IP/port. It is between signing the entire MIME >>>> body as a blob the auth service does not have to >> understand, versus >>>> selecting a set of elements (understood here not to include the >>>> IP/port) and signing those exclusively. If we want to >> understand the=20 >>>> benefits of the former approach, they go a bit beyond >> protecting the=20 >>>> IP/port. >>>> Architecturally, signing the blob results in better future >>>> compatibility and better paths to extending SDP. If the >>>> authentication service needs to know what elements in SDP >> are to be=20 >>>> included in the signature, then the authentication service >> behavior=20 >>>> needs to change every time that clients start using SDP >> (or bodies,=20 >>>> for that >>>> matter) in new ways. >>>>=20 >>>> If someone wakes up tomorrow, invents a new media security >> model, and=20 >>>> decides there is value in having an indicator in SDP that will let >>>> you correlate the rendezvous layer with media security >> keying, under=20 >>>> the blob model that indicator can just get stuck in SDP, and the >>>> authentication service does not need to change its >> behavior in order >>>> to sign it. >>>> Taking this to its extreme, while I'm sure no one would >> stand up to=20 >>>> defend SDPng these days, virtually everyone would say that >> SDP isn't=20 >>>> the ideal tool for establishing complicated sessions; if >> we ever do=20 >>>> get around to building something better, the >> authentication service >>>> in the blob signature model shouldn't need to understand >> it. This is,=20 >>>> again, just a basic SIP layering architecture we've always >> followed,=20 >>>> intended to maximize the ability of endpoints to innovate >> and reduce=20 >>>> the brittleness of intermediaries. >>>>=20 >>>> Even without looking to the future, I think there's >> reasonable value >>>> in signing most of the cruft in SDP. For example, as I've >> mentioned=20 >>>> before, I think it's worth detecting various codec >> downgrade sorts of >>>> attacks. But speaking to the IP/port again specifically, I >> maintain=20 >>>> that when sending media doesn't work, it is useful for UAS to >>>> ascertain who set the target IP/port, and if the IP/port >> shouldn't be=20 >>>> tried anyway because they were inserted by an attacker, I >> think it's=20 >>>> useful for the UAS to know that before it processes that >> re-INVITE,=20 >>>> or begins altering for that initial INVITE, or what have you. >>>>=20 >>>>>> broadly I >>>>>> think it doesn't address threats where an >>>> attacker/impersonator can >>>>>> accomplish their goals without ever establishing a >> session. If we=20 >>>>>> think about, I suspect we'll find there are actually quite >>>> a few of those. >>>>> [JRE] So this suggests the need for two solutions: one for >>>> protecting >>>>> the rendez-vous layer and one for protecting the media layer. The >>>>> problem is that the mechanism for protecting the >> rendez-vous layer >>>>> (RFC >>>>> 4474) does not work in certain deployment situations, and >>>> because we >>>>> reuse that for authenticating the media layer (using it >> to sign the=20 >>>>> fingerprint of the certificate used at the media layer) we >>>> are unable >>>>> to have protection of the media layer in those deployment >>>> situations. >>>>=20 >>>> Certainly I agree that RFC4474 interprets "certain deployment >>>> situations" as security violations, and that is a >> limitation of its >>>> approach. I was merely pointing out that there are also >> limitations=20 >>>> to an approach where we largely defer security to the media layer; >>>> namely, it no longer protects against classes of attacks >> that do not=20 >>>> intend to establish sessions as such (this discussion would come >>>> around to things like early media and forking, for >> example; there are >>>> also applicability concerns here with media protocols other than >>>> RTP). If these were the only two possible solutions, they >> we'd debate=20 >>>> their merits and flaws, pick one, and be done. I at least haven't >>>> given up on the idea that we can draw up some other candidate >>>> solutions; the real bar to doing so seems to me to be disagreement >>>> about the problem space. >>>> So for the moment, I am still trying to talk at a pretty >> high level=20 >>>> about what sorts of qualities are desirable in a solution. >>>>=20 >>>> Jon Peterson >>>> NeuStar, Inc. >>>>=20 >>>>> John >>>>=20 >>>>=20 >>=20 >>=20 From AUDET@nortel.com Fri Apr 10 13:44:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6909A3A695B for ; Fri, 10 Apr 2009 13:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bGvf+OokWd5 for ; Fri, 10 Apr 2009 13:44:20 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 701A93A680C for ; Fri, 10 Apr 2009 13:44:20 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3AKiPb18150; Fri, 10 Apr 2009 20:44:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Apr 2009 15:43:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D649045@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sABO07UAACAyOlAAKb4TA= References: <1ECE0EB50388174790F9694F77522CCF1D5F2B8B@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Jon Peterson" , "Elwell, John" , "Dean Willis" Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 20:44:21 -0000 Right, the signalling gets impersonated, but not the media. So the only practical thing that can be done by the attacker is interup media.=20 > -----Original Message----- > From: Jon Peterson [mailto:jon.peterson@neustar.biz]=20 > Sent: Friday, April 10, 2009 12:28 > To: Audet, Francois (SC100:3055); Elwell, John; Dean Willis > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 > If I may quibble here: >=20 > > The attack is not impersonation, it's interruption of media. >=20 > The attack relies on impersonation to accomplish interruption=20 > of media. The attacker listens to Alice's INVITE, and then=20 > sends a cut-and-pasted re-INVITE saying "This is Alice again,=20 > would you mind sending my media here instead please."=20 > Impersonation is almost always a tool that attackers use to=20 > accomplish some particular goal, even if it's just tricking=20 > you into accepting unwanted communications. I'm not sure I'd=20 > say impersonation is an attack as such, but by preventing it,=20 > we prevent whole categories of attacks and grant ourselves=20 > more powers in crafting authorization policies. From dworley@nortel.com Fri Apr 10 14:56:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749833A67F4; Fri, 10 Apr 2009 14:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPYfhP5G+0Q0; Fri, 10 Apr 2009 14:56:08 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2ECBC3A6985; Fri, 10 Apr 2009 14:55:44 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3ALuhu01175; Fri, 10 Apr 2009 21:56:43 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Apr 2009 17:56:42 -0400 From: "Dale Worley" To: Munjo Yu In-Reply-To: References: Content-Type: text/plain Organization: Nortel Networks Date: Fri, 10 Apr 2009 17:56:41 -0400 Message-Id: <1239400601.3742.71.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2009 21:56:42.0237 (UTC) FILETIME=[3B8D32D0:01C9BA27] Cc: sip@ietf.org, apps-discuss@ietf.org Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 21:56:09 -0000 On Wed, 2009-04-01 at 20:17 -0500, Munjo Yu wrote: > SET is described simply as follows, using a pair of braces: > > SET {Rule1 Rule2} As a start, I would like to see a fully accurate description of how the SET construction is written, and what its significance is. Given that SET is a *tool for writing specifications*, we must be careful to define it exactly. Currently, all we have is one example of its use. Dale From drage@alcatel-lucent.com Fri Apr 10 17:44:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646373A6891 for ; Fri, 10 Apr 2009 17:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[AWL=-1.842, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=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 Mhx9hOsObDpU for ; Fri, 10 Apr 2009 17:44:44 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 256AB3A6889 for ; Fri, 10 Apr 2009 17:44:43 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3B0jJeP003670 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 11 Apr 2009 02:45:19 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 11 Apr 2009 02:45:19 +0200 From: "DRAGE, Keith (Keith)" To: Hans Erik van Elburg Date: Sat, 11 Apr 2009 02:45:19 +0200 Thread-Topic: [Sip] Clarification on RFC 4458: SIP URIs for Applications such as Voicemail and Interactive Voice Response (IVR) Thread-Index: Acm5syte6sKHPhvzSIuIQB0ZVQL2nQAiCKIg Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D675883EFE@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <28B7C3AA2A7ABA4A841F11217ABE78D6758486E4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <9ae56b1e0904100105i351ff961wf9afac4b08938cee@mail.gmail.com> In-Reply-To: <9ae56b1e0904100105i351ff961wf9afac4b08938cee@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_28B7C3AA2A7ABA4A841F11217ABE78D675883EFEFRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "sip@ietf.org" , Cullen Jennings , Francois Audet , "Elwell, John" Subject: Re: [Sip] Clarification on RFC 4458: SIP URIs for Applications such as Voicemail and Interactive Voice Response (IVR) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 00:44:45 -0000 --_000_28B7C3AA2A7ABA4A841F11217ABE78D675883EFEFRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And which part of the wording in RFC 4458 do you use to justify that? The whole point of the question is that we are trying to ascertain what is = a legitimate conformance with RFC 4458. regards Keith ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans = Erik van Elburg Sent: Friday, April 10, 2009 9:06 AM To: DRAGE, Keith (Keith) Cc: sip@ietf.org; Cullen Jennings; Francois Audet; Elwell, John Subject: Re: [Sip] Clarification on RFC 4458: SIP URIs for Applications suc= h as Voicemail and Interactive Voice Response (IVR) Specifications that only include the cause value mappings as specified in R= FC4458 reuse only that part of RFC4458. Such reuse is of course fine, but carefull wording is required not to imply= full conformance with RFC4458 as that would lead to the wrong implications= /expectations. /Hans Erik van Elburg On Wed, Apr 8, 2009 at 6:06 PM, DRAGE, Keith (Keith) > wrote: RFC 4458 defines two SIP URI parameters. I can find no specific language in the document that indicates whether thes= e two URI parameters can be used independently of each other, or whether th= ere is an expectation that both URI parameters should only exist in the pre= sence of each other. Specifically does an implementation that only includes= the "cause" SIP URI parameter and not the "target" sip URI parameter confo= rm to this specification? All the text and examples seem to carry the implication that where one exis= ts, the other one will also. Could one of the authors or some other interested party clarify what they b= elieve the intention is? regards Keith _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the a= pplication of sip --_000_28B7C3AA2A7ABA4A841F11217ABE78D675883EFEFRMRSSXCHMBSB3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
And which part of the wording in RFC 4458 do you u= se to=20 justify that?
 
The whole point of the question is that we are try= ing to=20 ascertain what is a legitimate conformance with RFC 4458.
 
regards
 
Keith

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van=20 Elburg
Sent: Friday, April 10, 2009 9:06 AM
To: DRAGE= ,=20 Keith (Keith)
Cc: sip@ietf.org; Cullen Jennings; Francois Audet= ;=20 Elwell, John
Subject: Re: [Sip] Clarification on RFC 4458: SIP = URIs=20 for Applications such as Voicemail and Interactive Voice Response=20 (IVR)

Specifications that only include the cause value mappings as=20 specified in RFC4458 reuse only that part of RFC4458.

Such reuse = is of=20 course fine, but carefull wording is required not to imply full conforman= ce=20 with RFC4458 as that would lead to the wrong implications/expectations./Hans Erik van Elburg


On Wed, Apr 8, 2009 at 6:06 PM, DRAGE, Keith (Ke= ith)=20 <drage@alcatel-lucent.com>= =20 wrote:
RFC=20 4458 defines two SIP URI parameters.

I can find no specific lang= uage=20 in the document that indicates whether these two URI parameters can be = used=20 independently of each other, or whether there is an expectation that bo= th=20 URI parameters should only exist in the presence of each other. Specifi= cally=20 does an implementation that only includes the "cause" SIP URI parameter= and=20 not the "target" sip URI parameter conform to this specification?
All=20 the text and examples seem to carry the implication that where one exis= ts,=20 the other one will also.

Could one of the authors or some other= =20 interested party clarify what they believe the intention=20 is?

regards

Keith
____________________________________= ___________
Sip=20 mailing list  https://www.ietf.org/mailman/listinfo/sip
This l= ist is=20 for NEW development of the core SIP Protocol
Use sip-implementors@cs.co= lumbia.edu=20 for questions on current sip
Use sipping@ietf.org for new developme= nts on=20 the application of sip

--_000_28B7C3AA2A7ABA4A841F11217ABE78D675883EFEFRMRSSXCHMBSB3d_-- From john.elwell@siemens-enterprise.com Sat Apr 11 05:46:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5463A6E39 for ; Sat, 11 Apr 2009 05:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pTxd1t5uL-P for ; Sat, 11 Apr 2009 05:46:04 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 695053A6B06 for ; Sat, 11 Apr 2009 05:45:44 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHX00790SU32W@siemenscomms.co.uk> for sip@ietf.org; Sat, 11 Apr 2009 13:46:51 +0100 (BST) Date: Sat, 11 Apr 2009 13:46:51 +0100 From: "Elwell, John" In-reply-to: To: Jon Peterson , Francois Audet , Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001C1EDDB@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sAKwvW0A== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1D5A0946@zrc2hxm0.corp.nortel.com> Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 12:46:05 -0000 Jon, So a consequence of what you are saying is that to verify who you are = negotiating DTLS-SRTP security with you need one signature, covering the = certificate fingerprint and sufficient other stuff to prevent replay, = and to verify which intermediary told you the IP address and port to = send media to you need a second signature. Correct? John > -----Original Message----- > From: Jon Peterson [mailto:jon.peterson@neustar.biz]=20 > Sent: 10 April 2009 17:10 > To: Francois Audet; Elwell, John; Dean Willis > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > At a high level, when an intermediary is going to relay your=20 > media, the > intermediary (not the UAC) is the source of the IP/port data=20 > that appears in > SDP, and as such, I can accept alternatives to securing that=20 > data with a > signature from the originating administrative domain=20 > (abstractly, that goes > equally for SBCs and TURN, I suppose). I don't however=20 > believe it follows > from this that it just doesn't matter at all who sets the=20 > IP/port data in > SDP. I think it does matter, and it matters most when we=20 > consider approaches > that defer security checks from the SIP layer to the media layer. For > example, if relatively weak SIP-layer security facilitates=20 > cut-and-paste > attacks, then an eavesdropper could listen to INVITEs, forge=20 > re-INVITEs with > the same signature but set the IP/port to something unhelpful, and > methodically tear down a target's calls five seconds after=20 > they start. So > from my perspective, verifying the origin of IP/port data=20 > still has value, > even if the origin of that data is not the originating administrative > domain. >=20 > Jon Peterson > NeuStar, Inc. >=20 >=20 > On 4/9/09 12:09 PM, "Francois Audet" wrote: >=20 > > So, at a high level, if we could "sign the blob" =E0-la-RFC 4474, > > but exclude very specific elements (i.e., the IP:port), and combine > > it with DTLS-SRTP (or TLS for non-real time media), in specific > > cases where allowing Media Relays is desireable/necessary, then > > we may have a solution, right? > >=20 > > I'm interpreting your email as we should have an opt-out of > > integrity protection (carefully used) instead of an opt-in > > (as per the draft-wing-identity-media draft). > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Jon Peterson [mailto:jon.peterson@neustar.biz] > >> Sent: Thursday, April 09, 2009 11:50 > >> To: Elwell, John; Audet, Francois (SC100:3055); Dean Willis > >> Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > >> Subject: Re: [Sip] francois' comments and why RFC4474 not > >> used in the field > >>=20 > >>=20 > >>> [JRE] If media is encrypted, sending it to the wrong IP > >> address/port,=20 > >>> whilst it will cause the call to fail, will not reveal the > >> information=20 > >>> to the recipient. Of course, if media is not encrypted, > >> that has worse=20 > >>> consequences, but unencrypted media can be eavesdropped by other > >>> mechanisms, or can be spoofed or modified. Knowing who told > >> you which=20 > >>> IP address/port to send to only gives you a certain amount > >> of protection. > >>> We must ensure we do not lower the security available when > >> encryption=20 > >>> is in use (losing the ability to authenticate the user we=20 > performed > >>> key agreement with) by clinging on to mechanisms that give > >> some minor=20 > >>> benefit to the unencrypted case. > >>=20 > >> In fairness, I don't think the choice is between signing the > >> IP/port and not signing the IP/port. It is between signing > >> the entire MIME body as a blob the auth service does not have > >> to understand, versus selecting a set of elements (understood > >> here not to include the IP/port) and signing those > >> exclusively. If we want to understand the benefits of the > >> former approach, they go a bit beyond protecting the IP/port. > >> Architecturally, signing the blob results in better future > >> compatibility and better paths to extending SDP. If the > >> authentication service needs to know what elements in SDP are > >> to be included in the signature, then the authentication > >> service behavior needs to change every time that clients > >> start using SDP (or bodies, for that > >> matter) in new ways. > >>=20 > >> If someone wakes up tomorrow, invents a new media security > >> model, and decides there is value in having an indicator in > >> SDP that will let you correlate the rendezvous layer with > >> media security keying, under the blob model that indicator > >> can just get stuck in SDP, and the authentication service > >> does not need to change its behavior in order to sign it. > >> Taking this to its extreme, while I'm sure no one would stand > >> up to defend SDPng these days, virtually everyone would say > >> that SDP isn't the ideal tool for establishing complicated > >> sessions; if we ever do get around to building something > >> better, the authentication service in the blob signature > >> model shouldn't need to understand it. This is, again, just a > >> basic SIP layering architecture we've always followed, > >> intended to maximize the ability of endpoints to innovate and > >> reduce the brittleness of intermediaries. > >>=20 > >> Even without looking to the future, I think there's > >> reasonable value in signing most of the cruft in SDP. For > >> example, as I've mentioned before, I think it's worth > >> detecting various codec downgrade sorts of attacks. But > >> speaking to the IP/port again specifically, I maintain that > >> when sending media doesn't work, it is useful for UAS to > >> ascertain who set the target IP/port, and if the IP/port > >> shouldn't be tried anyway because they were inserted by an > >> attacker, I think it's useful for the UAS to know that before > >> it processes that re-INVITE, or begins altering for that > >> initial INVITE, or what have you. > >>=20 > >>>> broadly I > >>>> think it doesn't address threats where an > >> attacker/impersonator can > >>>> accomplish their goals without ever establishing a session. If we > >>>> think about, I suspect we'll find there are actually quite > >> a few of those. > >>> [JRE] So this suggests the need for two solutions: one for > >> protecting=20 > >>> the rendez-vous layer and one for protecting the media layer. The > >>> problem is that the mechanism for protecting the rendez-vous layer > >>> (RFC > >>> 4474) does not work in certain deployment situations, and > >> because we=20 > >>> reuse that for authenticating the media layer (using it=20 > to sign the > >>> fingerprint of the certificate used at the media layer) we > >> are unable=20 > >>> to have protection of the media layer in those deployment > >> situations. > >>=20 > >> Certainly I agree that RFC4474 interprets "certain deployment > >> situations" as security violations, and that is a limitation > >> of its approach. I was merely pointing out that there are > >> also limitations to an approach where we largely defer > >> security to the media layer; namely, it no longer protects > >> against classes of attacks that do not intend to establish > >> sessions as such (this discussion would come around to things > >> like early media and forking, for example; there are also > >> applicability concerns here with media protocols other than > >> RTP). If these were the only two possible solutions, they > >> we'd debate their merits and flaws, pick one, and be done. I > >> at least haven't given up on the idea that we can draw up > >> some other candidate solutions; the real bar to doing so > >> seems to me to be disagreement about the problem space. > >> So for the moment, I am still trying to talk at a pretty high > >> level about what sorts of qualities are desirable in a solution. > >>=20 > >> Jon Peterson > >> NeuStar, Inc. > >>=20 > >>> John > >>=20 > >>=20 >=20 >=20 From john.elwell@siemens-enterprise.com Sat Apr 11 05:48:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63813A6E38 for ; Sat, 11 Apr 2009 05:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=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 Wq2ruUO4ypQu for ; Sat, 11 Apr 2009 05:48:19 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 146A13A6E31 for ; Sat, 11 Apr 2009 05:48:19 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHX007A2SYG2W@siemenscomms.co.uk> for sip@ietf.org; Sat, 11 Apr 2009 13:49:28 +0100 (BST) Date: Sat, 11 Apr 2009 13:49:27 +0100 From: "Elwell, John" In-reply-to: <9ae56b1e0904100136n4820db6dud334333a15ffeef7@mail.gmail.com> To: Hans Erik van Elburg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001C1EDDC@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C9BAA3.F2DC0011" Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm5t21m1H2BpOGJTHqpnEwXYfba7wA7C05Q Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001BEA9B6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1D5A0946@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D001C1EDC1@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0904100136n4820db6dud334333a15ffeef7@mail.gmail.com> Cc: Cullen Jennings , Jon Peterson , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 12:48:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BAA3.F2DC0011 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Technically you are correct, of course, but in many practical situations the UAS implicitly knows the final target AoR based on the contact URI received in the Request-URI. Also with the proposed change to History-Info it would receive an explicit indication. I don't think this impacts my argument. =20 John ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: 10 April 2009 09:36 To: Elwell, John Cc: Francois Audet; Jon Peterson; Dean Willis; Cullen Jennings; sip@ietf.org; DRAGE, Keith (Keith) Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field =09 =09 But the UAS will mostly receive its own contact address in the Request-URI, so there is not much to judge there.=20 =09 /Hans Erik van Elburg =09 =09 =09 On Fri, Apr 10, 2009 at 10:03 AM, Elwell, John wrote: =09 So the verifier or UAS knows for sure where the request was originally targeted and has to use its own judgement as to whether the changed Request-URI is reasonable or not. ------_=_NextPart_001_01C9BAA3.F2DC0011 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Technically you are correct, of course, but in many = practical=20 situations the UAS implicitly knows the final target AoR based on the = contact=20 URI received in the Request-URI. Also with the proposed change to = History-Info=20 it would receive an explicit indication. I don't think this impacts my=20 argument.
 
John

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: 10 April 2009=20 09:36
To: Elwell, John
Cc: Francois Audet; Jon = Peterson;=20 Dean Willis; Cullen Jennings; sip@ietf.org; DRAGE, Keith=20 (Keith)
Subject: Re: [Sip] francois' comments and why = RFC4474 not=20 used in the field

But the UAS will mostly receive its own contact address in = the=20 Request-URI, so there is not much to judge there.

/Hans Erik=20 van Elburg


On Fri, Apr 10, 2009 at 10:03 AM, Elwell, = John <john.elwell@siemens-en= terprise.com>=20 wrote:
So the verifier or UAS knows for sure = where the=20 request was originally targeted and has to use its own judgement as = to=20 whether the changed Request-URI is reasonable or=20 not.

------_=_NextPart_001_01C9BAA3.F2DC0011-- From ietf.hanserik@gmail.com Sun Apr 12 04:38:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A1F3A69DB for ; Sun, 12 Apr 2009 04:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 ZNFM1hS3VVSR for ; Sun, 12 Apr 2009 04:38:41 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 842223A6A4B for ; Sun, 12 Apr 2009 04:38:40 -0700 (PDT) Received: by ewy9 with SMTP id 9so1756652ewy.37 for ; Sun, 12 Apr 2009 04:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=JJqwt+x+GfWN4GJI4XbPBBqq2aHKM3Vtg2irRN+9acA=; b=vCR4klWdQ8OEinIDziOur4RAJO5we4TFAMT3FpOuMmyJX8ScDtBpgEuMDewJtrvuTh VS7LgxOBfip5qHZ+4g824tAH2+nrzRCSfzsSH+Wt3QpmGDR3J7CGq+ZBkodc0wnizDn/ N2CtFRN86pC7eglvCMZkH6BbCAwQpkyVkQ6Wg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=eAgbNHKDmLhtCiJ+XsWM+cKMon76/WQ74vL0qc2BgBvnBvF6N79pfX4saZ7PQa9AYq faQEwl4eHwXGbm9NaNXhJocIi7aHyNrR3mftgstUzWrkmUX03WEOfgvxjr7jMkshYTOe kCwURR/3dFnM2XbBjIX7xfStxn+3tuJQlE5AE= Received: by 10.216.7.83 with SMTP id 61mr1280166weo.167.1239536389530; Sun, 12 Apr 2009 04:39:49 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id q9sm9374923gve.3.2009.04.12.04.39.48 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Apr 2009 04:39:49 -0700 (PDT) Message-ID: <49E1D303.6080501@gmail.com> Date: Sun, 12 Apr 2009 13:39:47 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <28B7C3AA2A7ABA4A841F11217ABE78D6758486E4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <9ae56b1e0904100105i351ff961wf9afac4b08938cee@mail.gmail.com> <28B7C3AA2A7ABA4A841F11217ABE78D675883EFE@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D675883EFE@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Cullen Jennings , Francois Audet , "Elwell, John" Subject: Re: [Sip] Clarification on RFC 4458: SIP URIs for Applications such as Voicemail and Interactive Voice Response (IVR) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 11:38:41 -0000 OK, I assumed the question arose because of usage of RFC4458 cause value mapping as indicated in my previous mail. My assumption might be wrong. Going over RFC4458 again, it does not specify what proxies complying to this RFC should do. Therefore claiming compliance might be pretty meaningless. But if you look at the descriptive text and the examples it seems to indicate that both parameters will be added . /Hans Erik DRAGE, Keith (Keith) wrote: > And which part of the wording in RFC 4458 do you use to justify that? > > The whole point of the question is that we are trying to ascertain > what is a legitimate conformance with RFC 4458. > > regards > > Keith > > ------------------------------------------------------------------------ > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On > Behalf Of *Hans Erik van Elburg > *Sent:* Friday, April 10, 2009 9:06 AM > *To:* DRAGE, Keith (Keith) > *Cc:* sip@ietf.org; Cullen Jennings; Francois Audet; Elwell, John > *Subject:* Re: [Sip] Clarification on RFC 4458: SIP URIs for > Applications such as Voicemail and Interactive Voice Response (IVR) > > Specifications that only include the cause value mappings as > specified in RFC4458 reuse only that part of RFC4458. > > Such reuse is of course fine, but carefull wording is required not > to imply full conformance with RFC4458 as that would lead to the > wrong implications/expectations. > > /Hans Erik van Elburg > > > On Wed, Apr 8, 2009 at 6:06 PM, DRAGE, Keith (Keith) > > wrote: > > RFC 4458 defines two SIP URI parameters. > > I can find no specific language in the document that indicates > whether these two URI parameters can be used independently of > each other, or whether there is an expectation that both URI > parameters should only exist in the presence of each other. > Specifically does an implementation that only includes the > "cause" SIP URI parameter and not the "target" sip URI > parameter conform to this specification? > > All the text and examples seem to carry the implication that > where one exists, the other one will also. > > Could one of the authors or some other interested party > clarify what they believe the intention is? > > regards > > Keith > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu > for questions on > current sip > Use sipping@ietf.org for new > developments on the application of sip > > From florz@florz.de Sun Apr 12 19:53:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCA73A69F6 for ; Sun, 12 Apr 2009 19:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[AWL=2.063, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D19Zum8wJ61 for ; Sun, 12 Apr 2009 19:53:29 -0700 (PDT) Received: from rain.florz.dyndns.org (rain.florz.de [62.216.164.86]) by core3.amsl.com (Postfix) with ESMTP id 17CBD3A6883 for ; Sun, 12 Apr 2009 19:53:29 -0700 (PDT) Received: from florz.florz.dyndns.org ([192.168.0.121]) by rain.florz.dyndns.org with esmtp (Exim 4.63) (envelope-from ) id 1LtCJb-0005PO-QA; Mon, 13 Apr 2009 04:54:31 +0200 Received: from florz by florz.florz.dyndns.org with local (Exim 3.35 #1 (Debian)) id 1LtCJb-0001FO-00; Mon, 13 Apr 2009 04:54:31 +0200 Date: Mon, 13 Apr 2009 04:54:31 +0200 From: Florian Zumbiehl To: sip@ietf.org Message-ID: <20090413025431.GB7795@florz.florz.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: [Sip] bug in draft-ietf-sip-gruu-15 grammar X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 03:01:04 -0000 Hi, draft-ietf-sip-gruu-15 contains (amongst others) these ABNF rules: | contact-params =/ temp-gruu / pub-gruu | temp-gruu = "temp-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) | RDQUOT | pub-gruu = "pub-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) | RDQUOT which, when adding them to the grammar from RFC 3261, would produce from a language that's a superset of the language that would be produced by from RFC 3261-only. In particular, the language produced by is a subset of the "GRUU extended" language, but not of the RFC 3261-only one: | foo = "m: ;temp-gruu=" DQUOTE "x" DQUOTE SP CRLF To put it in more practical terms: the in both and allow for trailing , which does not, so an implementation conforming to draft-ietf-sip-gruu-15 could produce a Contact header that potentially could not be parsable (except as an ) by an implementation conforming to RFC 3261. Thus, I would suggest to replace the rules quoted above by: | contact-params =/ temp-gruu / pub-gruu | temp-gruu = "temp-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) | DQUOTE | pub-gruu = "pub-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) | DQUOTE This produces the same language, maybe it's a better replacement: | contact-params =/ temp-gruu / pub-gruu | temp-gruu = "temp-gruu" EQUAL quoted-string | pub-gruu = "pub-gruu" EQUAL quoted-string Florian From apike3@csc.com Mon Apr 13 06:14:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB2C3A6D83 for ; Mon, 13 Apr 2009 06:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.752 X-Spam-Level: X-Spam-Status: No, score=-4.752 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_55=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zveTBY2YqGIf for ; Mon, 13 Apr 2009 06:14:53 -0700 (PDT) Received: from mail63.messagelabs.com (mail63.messagelabs.com [216.82.242.83]) by core3.amsl.com (Postfix) with ESMTP id 3F6923A6D94 for ; Mon, 13 Apr 2009 06:14:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: apike3@csc.com X-Msg-Ref: server-2.tower-63.messagelabs.com!1239628560!76952672!3 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 23884 invoked from network); 13 Apr 2009 13:16:02 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-2.tower-63.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Apr 2009 13:16:02 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n3DDG00E001343; Mon, 13 Apr 2009 09:16:02 -0400 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D649045@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1D5F2B8B@zrc2hxm0.corp.nortel.com> , <1ECE0EB50388174790F9694F77522CCF1D649045@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 From: Anthony D Pike To: "Francois Audet" Message-ID: Date: Mon, 13 Apr 2009 09:15:58 -0400 X-Mailer: Lotus Domino Web Server Release 8.0.1 February 07, 2008 X-MIMETrack: Serialize by Notes Server on AMER-ML20/SRV/CSC(Release 8.0.1|February 07, 2008) at 04/13/2009 09:15:58, Serialize complete at 04/13/2009 09:15:58, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 04/13/2009 09:18:07 AM MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , Jon Peterson , sip@ietf.org, "DRAGE, Keith \(Keith\)" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 13:14:54 -0000

hi Francios,

Surely if you correlate the signallng with the&n= bsp;initial media stream from the endpoint as Jonathan mentioned in hi= s original email a couple of weeks ago then you will know that that there h= as been a problem and you would not pick up the call and you migh= t report the call to the appropriate authorities who could then trace the c= all potentailly.

Quite how this correlation takes place is not 100% c= lear to me as yet, but I'm thinking on it.

Tony  
This is a PRIVATE message. If you are not= the intended recipient, please delete without copying and kindly advise us= by e-mail of the mistake in delivery.
NOTE: Regardless of content, thi= s e-mail shall not operate to bind CSC to any order or other contract unles= s pursuant to explicit written agreement or government initiative expressly= permitting the use of e-mail for such purpose. =E2=80=A2 


-----sip-bounces@ietf.org wrote: -----

To: "Jon Peterson" <jon.peterson@ne= ustar.biz>, "Elwell, John" <john.elwell@siemens-enterprise.com>, "= Dean Willis" <dean.willis@softarmor.com>
From: "Francois Audet" &l= t;audet@nortel.com>
Sent by: sip-bounces@ietf.org
Date: 04/10/2009= 04:43PM
cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org, "DR= AGE, Keith \(Keith\)" <drage@alcatel-lucent.com>
Subject: Re: [Sip= ] francois' comments and why RFC4474 not used in the field

Right, the s= ignalling gets impersonated, but not the media.

So the only practica= l thing that can be done by the attacker
is interup media.

> = -----Original Message-----
> From: Jon Peterson [mailto:jon.peterson@neustar.biz= ]
> Sent: Friday, April 10, 2009 12:28
> To: Audet, Francois (= SC100:3055); Elwell, John; Dean Willis
> Cc: Cullen Jennings; sip@iet= f.org; DRAGE,Keith (Keith)
> Subject: Re: [Sip] francois' comments an= d why RFC4474 not
> used in the field
>
> If I may quib= ble here:
>
> > The attack is not impersonation, it's inter= ruption of media.
>
> The attack relies on impersonation to ac= complish interruption
> of media. The attacker listens to Alice's IN= VITE, and then
> sends a cut-and-pasted re-INVITE saying "This is Al= ice again,
> would you mind sending my media here instead please." <= BR>> Impersonation is almost always a tool that attackers use to
>= ; accomplish some particular goal, even if it's just tricking
> you = into accepting unwanted communications. I'm not sure I'd
> say imper= sonation is an attack as such, but by preventing it,
> we prevent wh= ole categories of attacks and grant ourselves
> more powers in craft= ing authorization policies.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F
Sip mailing list  https://www.ietf.org/mailman/= listinfo/sip
This list is for NEW development of the core SIP Protoc= ol
Use sip-implementors@cs.columbia.edu for questions on current sip
= Use sipping@ietf.org for new developments on the application of sip

= From aallen@rim.com Mon Apr 13 07:19:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A28F3A6DB8 for ; Mon, 13 Apr 2009 07:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.047 X-Spam-Level: X-Spam-Status: No, score=-5.047 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLW9haOlA3YL for ; Mon, 13 Apr 2009 07:19:30 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 3A4213A6DAD for ; Mon, 13 Apr 2009 07:19:29 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 6C0AF5876D for ; Mon, 13 Apr 2009 10:20:39 -0400 (EDT) X-AuditID: 0a401fcb-a51aabb000002ba2-94-49e34a37da97 Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 4945A5874D for ; Mon, 13 Apr 2009 10:20:39 -0400 (EDT) Received: from XCH47YKF.rim.net ([10.64.31.217]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Apr 2009 10:20:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Mon, 13 Apr 2009 10:20:37 -0400 Message-ID: <61968779B8AC4C4BAB421D4C12F008C01C74814A@XCH47YKF.rim.net> In-Reply-To: <20090413025431.GB7795@florz.florz.dyndns.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] bug in draft-ietf-sip-gruu-15 grammar Thread-Index: Acm75Ei+NbuoHpkhRUuoidLgkv4IZAAXVIiw References: <20090413025431.GB7795@florz.florz.dyndns.org> From: "Andrew Allen" To: X-OriginalArrivalTime: 13 Apr 2009 14:20:39.0171 (UTC) FILETIME=[0521ED30:01C9BC43] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] bug in draft-ietf-sip-gruu-15 grammar X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 14:19:31 -0000 If a revision of GRUU 15 is needed then I have one more issue that I recently identified to be considered in any update. In 5.1 Processing of a GRUU The text seems to indicate that the registrar allocates GRUUs for every Contact that includes the "+sip.instance" header field parameter. However "+sip.instance" can be used by UAs that support only outbound and not GRUU so first the registrar should check that "gruu" option tag is included by the UA in a Require or Supported header before checking for "+sip.instance" header field parameters in the Contacts and allocating GRUUs. There doesn't seem any point in the Registrar allocating GRUUs if the UA doesn't support them. Andrew -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Florian Zumbiehl Sent: Sunday, April 12, 2009 10:55 PM To: sip@ietf.org Subject: [Sip] bug in draft-ietf-sip-gruu-15 grammar Hi, draft-ietf-sip-gruu-15 contains (amongst others) these ABNF rules: | contact-params =3D/ temp-gruu / pub-gruu | temp-gruu =3D "temp-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) | RDQUOT | pub-gruu =3D "pub-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) | RDQUOT which, when adding them to the grammar from RFC 3261, would produce from a language that's a superset of the language that would be produced by from RFC 3261-only. In particular, the language produced by is a subset of the "GRUU extended" language, but not of the RFC 3261-only one: | foo =3D "m: ;temp-gruu=3D" DQUOTE "x" DQUOTE SP CRLF To put it in more practical terms: the in both and allow for trailing , which does not, so an implementation conforming to draft-ietf-sip-gruu-15 could produce a Contact header that potentially could not be parsable (except as an ) by an implementation conforming to RFC 3261. Thus, I would suggest to replace the rules quoted above by: | contact-params =3D/ temp-gruu / pub-gruu | temp-gruu =3D "temp-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) | DQUOTE | pub-gruu =3D "pub-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) | DQUOTE This produces the same language, maybe it's a better replacement: | contact-params =3D/ temp-gruu / pub-gruu | temp-gruu =3D "temp-gruu" EQUAL quoted-string | pub-gruu =3D "pub-gruu" EQUAL quoted-string Florian _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From pkyzivat@cisco.com Mon Apr 13 07:48:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FFE13A6BD7 for ; Mon, 13 Apr 2009 07:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.984 X-Spam-Level: X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0tzWz6v3pLN for ; Mon, 13 Apr 2009 07:48:35 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E84AF3A686C for ; Mon, 13 Apr 2009 07:48:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,180,1238976000"; d="scan'208";a="41775414" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2009 14:49:45 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3DEnjgR025913; Mon, 13 Apr 2009 10:49:45 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3DEnj59011139; Mon, 13 Apr 2009 14:49:45 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Apr 2009 10:49:45 -0400 Received: from [161.44.182.253] ([161.44.182.253]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Apr 2009 10:49:44 -0400 Message-ID: <49E35108.4080506@cisco.com> Date: Mon, 13 Apr 2009 10:49:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andrew Allen References: <20090413025431.GB7795@florz.florz.dyndns.org> <61968779B8AC4C4BAB421D4C12F008C01C74814A@XCH47YKF.rim.net> In-Reply-To: <61968779B8AC4C4BAB421D4C12F008C01C74814A@XCH47YKF.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2009 14:49:44.0825 (UTC) FILETIME=[159F9690:01C9BC47] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4820; t=1239634185; x=1240498185; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20bug=20in=20draft-ietf-sip-gruu- 15=20grammar |Sender:=20 |To:=20Andrew=20Allen=20; bh=qrgnTDytNBSlnZnGKypMqFWDaFOUKmP50/Visow+wRI=; b=n+1/JYVaxKxc25YtDzGB9BJ73PqKH9Uslaw1gUHwYHdTDWdMTlKeAp0XqP RFqr873NWz1QSLugtlkmJD70LFiLyYAy19YbOjCNykbvjSQjIZrpMqEbj9P8 rbkFInmaYZ; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] bug in draft-ietf-sip-gruu-15 grammar X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 14:48:36 -0000 Andrew, Its been quite awhile and my memory may be getting a little fuzzy on this, but... As I recall there are some very subtle points about this. There are cases where someone other than the UA doing the registering may need the gruu. So the UA that registers its contact may not support GRUU, the gruu need be allocated so others can use it. For instance, if some other UA registers the same AOR, and does support gruu, it will get back all the contacts, and should get back gruus for all of them. Similarly, any who subscribe to the reg event package. As I recall, the "hello world" example (in the gruu reg event package?) would depend on this. Of course the registrar need not actually assign the gruu until something happens that will result in it being observed. Thanks, Paul Andrew Allen wrote: > If a revision of GRUU 15 is needed then I have one more issue that I > recently identified to be considered in any update. > > In 5.1 Processing of a GRUU > > The text seems to indicate that the registrar allocates GRUUs for every > Contact that includes the "+sip.instance" header field parameter. > However "+sip.instance" can be used by UAs that support only outbound > and not GRUU so first the registrar should check that "gruu" option tag > is included by the UA in a Require or Supported header before checking > for "+sip.instance" header field parameters in the Contacts and > allocating GRUUs. There doesn't seem any point in the Registrar > allocating GRUUs if the UA doesn't support them. > > Andrew > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Florian Zumbiehl > Sent: Sunday, April 12, 2009 10:55 PM > To: sip@ietf.org > Subject: [Sip] bug in draft-ietf-sip-gruu-15 grammar > > Hi, > > draft-ietf-sip-gruu-15 contains (amongst others) these ABNF rules: > > | contact-params =/ temp-gruu / pub-gruu > | temp-gruu = "temp-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) > | RDQUOT > | pub-gruu = "pub-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) > | RDQUOT > > which, when adding them to the grammar from RFC 3261, would produce > from a language that's a superset of the language that would > be produced by from RFC 3261-only. > > In particular, the language produced by is a subset of the > "GRUU extended" language, but not of the RFC 3261-only one: > > | foo = "m: ;temp-gruu=" DQUOTE "x" DQUOTE SP CRLF > > To put it in more practical terms: the in both and > allow for trailing , which does > not, so an implementation conforming to draft-ietf-sip-gruu-15 could > produce a Contact header that potentially could not be parsable > (except as an ) by an implementation conforming > to RFC 3261. > > Thus, I would suggest to replace the rules quoted above by: > > | contact-params =/ temp-gruu / pub-gruu > | temp-gruu = "temp-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) > | DQUOTE > | pub-gruu = "pub-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) > | DQUOTE > > This produces the same language, maybe it's a better replacement: > > | contact-params =/ temp-gruu / pub-gruu > | temp-gruu = "temp-gruu" EQUAL quoted-string > | pub-gruu = "pub-gruu" EQUAL quoted-string > > Florian > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From AUDET@nortel.com Mon Apr 13 09:02:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D053A6DB0 for ; Mon, 13 Apr 2009 09:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.042 X-Spam-Level: X-Spam-Status: No, score=-6.042 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAhFIdmFolAe for ; Mon, 13 Apr 2009 09:02:17 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3C8A33A6DEC for ; Mon, 13 Apr 2009 09:02:17 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3DG2uM01149; Mon, 13 Apr 2009 16:02:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BC51.4E88BD08" Date: Mon, 13 Apr 2009 11:02:54 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D649A2D@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm8Ogo+oVEWQX4PToKPL1Xf8vEnWgAFzPZA References: <1ECE0EB50388174790F9694F77522CCF1D5F2B8B@zrc2hxm0.corp.nortel.com> , <1ECE0EB50388174790F9694F77522CCF1D649045@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Anthony D Pike" Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" , Jon Peterson , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 16:02:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BC51.4E88BD08 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZS4NCiANCkkgdGhpbmsgdGhlIGlzc3VlIEpvbiBpcyBwb2ludGluZyBvdXQgaXMgdGhh dCBvbmUgY291bGQgaW50ZXJydXB0IHRoZSBtZWRpYSBzdHJlYW0uDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KCUZyb206IHNpcC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86c2lwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbnRob255IEQgUGlrZQ0KCVNl bnQ6IE1vbmRheSwgQXByaWwgMTMsIDIwMDkgMDY6MTYNCglUbzogQXVkZXQsIEZyYW5jb2lzIChT QzEwMDozMDU1KQ0KCUNjOiBDdWxsZW4gSmVubmluZ3M7IEpvbiBQZXRlcnNvbjsgc2lwQGlldGYu b3JnOyBEUkFHRSwgS2VpdGggKEtlaXRoKTsgRGVhbiBXaWxsaXMNCglTdWJqZWN0OiBSZTogW1Np cF0gZnJhbmNvaXMnIGNvbW1lbnRzIGFuZCB3aHkgUkZDNDQ3NCBub3QgdXNlZCBpbiB0aGUgZmll bGQNCgkNCgkNCgloaSBGcmFuY2lvcywNCg0KCVN1cmVseSBpZiB5b3UgY29ycmVsYXRlIHRoZSBz aWduYWxsbmcgd2l0aCB0aGUgaW5pdGlhbCBtZWRpYSBzdHJlYW0gZnJvbSB0aGUgZW5kcG9pbnQg YXMgSm9uYXRoYW4gbWVudGlvbmVkIGluIGhpcyBvcmlnaW5hbCBlbWFpbCBhIGNvdXBsZSBvZiB3 ZWVrcyBhZ28gdGhlbiB5b3Ugd2lsbCBrbm93IHRoYXQgdGhhdCB0aGVyZSBoYXMgYmVlbiBhIHBy b2JsZW0gYW5kIHlvdSB3b3VsZCBub3QgcGljayB1cCB0aGUgY2FsbCBhbmQgeW91IG1pZ2h0IHJl cG9ydCB0aGUgY2FsbCB0byB0aGUgYXBwcm9wcmlhdGUgYXV0aG9yaXRpZXMgd2hvIGNvdWxkIHRo ZW4gdHJhY2UgdGhlIGNhbGwgcG90ZW50YWlsbHkuDQoNCglRdWl0ZSBob3cgdGhpcyBjb3JyZWxh dGlvbiB0YWtlcyBwbGFjZSBpcyBub3QgMTAwJSBjbGVhciB0byBtZSBhcyB5ZXQsIGJ1dCBJJ20g dGhpbmtpbmcgb24gaXQuDQoJDQoNCglUb255ICANCgkNCglUaGlzIGlzIGEgUFJJVkFURSBtZXNz YWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRl IHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1p c3Rha2UgaW4gZGVsaXZlcnkuIA0KCU5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBl LW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVy IGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBv ciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBl LW1haWwgZm9yIHN1Y2ggcHVycG9zZS4g4oCiIA0KDQoNCgktLS0tLXNpcC1ib3VuY2VzQGlldGYu b3JnIHdyb3RlOiAtLS0tLQ0KCQ0KCQ0KDQoJCVRvOiAiSm9uIFBldGVyc29uIiA8am9uLnBldGVy c29uQG5ldXN0YXIuYml6PiwgIkVsd2VsbCwgSm9obiIgPGpvaG4uZWx3ZWxsQHNpZW1lbnMtZW50 ZXJwcmlzZS5jb20+LCAiRGVhbiBXaWxsaXMiIDxkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tPg0K CQlGcm9tOiAiRnJhbmNvaXMgQXVkZXQiIDxhdWRldEBub3J0ZWwuY29tPg0KCQlTZW50IGJ5OiBz aXAtYm91bmNlc0BpZXRmLm9yZw0KCQlEYXRlOiAwNC8xMC8yMDA5IDA0OjQzUE0NCgkJY2M6IEN1 bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGNpc2NvLmNvbT4sIHNpcEBpZXRmLm9yZywgIkRSQUdFLCBL ZWl0aCBcKEtlaXRoXCkiIDxkcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20+DQoJCVN1YmplY3Q6IFJl OiBbU2lwXSBmcmFuY29pcycgY29tbWVudHMgYW5kIHdoeSBSRkM0NDc0IG5vdCB1c2VkIGluIHRo ZSBmaWVsZA0KCQkNCgkJUmlnaHQsIHRoZSBzaWduYWxsaW5nIGdldHMgaW1wZXJzb25hdGVkLCBi dXQgbm90IHRoZSBtZWRpYS4NCgkJDQoJCVNvIHRoZSBvbmx5IHByYWN0aWNhbCB0aGluZyB0aGF0 IGNhbiBiZSBkb25lIGJ5IHRoZSBhdHRhY2tlcg0KCQlpcyBpbnRlcnVwIG1lZGlhLiANCgkJDQoJ CT4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgkJPiBGcm9tOiBKb24gUGV0ZXJzb24gW21h aWx0bzpqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXpdIA0KCQk+IFNlbnQ6IEZyaWRheSwgQXByaWwg MTAsIDIwMDkgMTI6MjgNCgkJPiBUbzogQXVkZXQsIEZyYW5jb2lzIChTQzEwMDozMDU1KTsgRWx3 ZWxsLCBKb2huOyBEZWFuIFdpbGxpcw0KCQk+IENjOiBDdWxsZW4gSmVubmluZ3M7IHNpcEBpZXRm Lm9yZzsgRFJBR0UsS2VpdGggKEtlaXRoKQ0KCQk+IFN1YmplY3Q6IFJlOiBbU2lwXSBmcmFuY29p cycgY29tbWVudHMgYW5kIHdoeSBSRkM0NDc0IG5vdCANCgkJPiB1c2VkIGluIHRoZSBmaWVsZA0K CQk+IA0KCQk+IElmIEkgbWF5IHF1aWJibGUgaGVyZToNCgkJPiANCgkJPiA+IFRoZSBhdHRhY2sg aXMgbm90IGltcGVyc29uYXRpb24sIGl0J3MgaW50ZXJydXB0aW9uIG9mIG1lZGlhLg0KCQk+IA0K CQk+IFRoZSBhdHRhY2sgcmVsaWVzIG9uIGltcGVyc29uYXRpb24gdG8gYWNjb21wbGlzaCBpbnRl cnJ1cHRpb24gDQoJCT4gb2YgbWVkaWEuIFRoZSBhdHRhY2tlciBsaXN0ZW5zIHRvIEFsaWNlJ3Mg SU5WSVRFLCBhbmQgdGhlbiANCgkJPiBzZW5kcyBhIGN1dC1hbmQtcGFzdGVkIHJlLUlOVklURSBz YXlpbmcgIlRoaXMgaXMgQWxpY2UgYWdhaW4sIA0KCQk+IHdvdWxkIHlvdSBtaW5kIHNlbmRpbmcg bXkgbWVkaWEgaGVyZSBpbnN0ZWFkIHBsZWFzZS4iIA0KCQk+IEltcGVyc29uYXRpb24gaXMgYWxt b3N0IGFsd2F5cyBhIHRvb2wgdGhhdCBhdHRhY2tlcnMgdXNlIHRvIA0KCQk+IGFjY29tcGxpc2gg c29tZSBwYXJ0aWN1bGFyIGdvYWwsIGV2ZW4gaWYgaXQncyBqdXN0IHRyaWNraW5nIA0KCQk+IHlv dSBpbnRvIGFjY2VwdGluZyB1bndhbnRlZCBjb21tdW5pY2F0aW9ucy4gSSdtIG5vdCBzdXJlIEkn ZCANCgkJPiBzYXkgaW1wZXJzb25hdGlvbiBpcyBhbiBhdHRhY2sgYXMgc3VjaCwgYnV0IGJ5IHBy ZXZlbnRpbmcgaXQsIA0KCQk+IHdlIHByZXZlbnQgd2hvbGUgY2F0ZWdvcmllcyBvZiBhdHRhY2tz IGFuZCBncmFudCBvdXJzZWx2ZXMgDQoJCT4gbW9yZSBwb3dlcnMgaW4gY3JhZnRpbmcgYXV0aG9y aXphdGlvbiBwb2xpY2llcy4NCgkJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCgkJU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXANCgkJVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2Yg dGhlIGNvcmUgU0lQIFByb3RvY29sDQoJCVVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlh LmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQoJCVVzZSBzaXBwaW5nQGlldGYub3Jn IGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCgkJDQoNCg0K ------_=_NextPart_001_01C9BC51.4E88BD08 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxTUEFO IGNsYXNzPTcxNzI3MDIxNi0xMzA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4MDAwMDAg c2l6ZT0yPkkgDQphZ3JlZS48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz03 MTcyNzAyMTYtMTMwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jODAwMDAwIA0Kc2l6ZT0y PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTcxNzI3MDIxNi0x MzA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPkkgDQp0aGluayB0 aGUgaXNzdWUgSm9uIGlzIHBvaW50aW5nIG91dCBpcyB0aGF0IG9uZSBjb3VsZCBpbnRlcnJ1cHQg dGhlIG1lZGlhIA0Kc3RyZWFtLjwvRk9OVD48L1NQQU4+PC9ESVY+PEJSPg0KPEJMT0NLUVVPVEUg DQpzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZU OiAjODAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIGNsYXNzPU91 dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KICA8SFIg dGFiSW5kZXg9LTE+DQogIDxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9tOjwvQj4gc2lw LWJvdW5jZXNAaWV0Zi5vcmcgDQogIFttYWlsdG86c2lwLWJvdW5jZXNAaWV0Zi5vcmddIDxCPk9u IEJlaGFsZiBPZiA8L0I+QW50aG9ueSBEIA0KICBQaWtlPEJSPjxCPlNlbnQ6PC9CPiBNb25kYXks IEFwcmlsIDEzLCAyMDA5IDA2OjE2PEJSPjxCPlRvOjwvQj4gQXVkZXQsIA0KICBGcmFuY29pcyAo U0MxMDA6MzA1NSk8QlI+PEI+Q2M6PC9CPiBDdWxsZW4gSmVubmluZ3M7IEpvbiBQZXRlcnNvbjsg DQogIHNpcEBpZXRmLm9yZzsgRFJBR0UsIEtlaXRoIChLZWl0aCk7IERlYW4gV2lsbGlzPEJSPjxC PlN1YmplY3Q6PC9CPiBSZTogW1NpcF0gDQogIGZyYW5jb2lzJyBjb21tZW50cyBhbmQgd2h5IFJG QzQ0NzQgbm90IHVzZWQgaW4gdGhlIGZpZWxkPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogIDxESVY+ PC9ESVY+PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLFZlcmRhbmEsQXJpYWwsSGVsdmV0 aWNhLHNhbnMtc2VyaWYiIA0KICBzaXplPTI+DQogIDxQPmhpIEZyYW5jaW9zLDwvUD4NCiAgPFA+ U3VyZWx5IGlmIHlvdSBjb3JyZWxhdGUgdGhlIHNpZ25hbGxuZyB3aXRoIHRoZSZuYnNwO2luaXRp YWwgbWVkaWEgDQogIHN0cmVhbSZuYnNwO2Zyb20gdGhlIGVuZHBvaW50IGFzIEpvbmF0aGFuIG1l bnRpb25lZCBpbiBoaXMgb3JpZ2luYWwgZW1haWwgYSANCiAgY291cGxlIG9mIHdlZWtzIGFnbyB0 aGVuIHlvdSB3aWxsIGtub3cgdGhhdCB0aGF0IHRoZXJlIGhhcyBiZWVuIGEgcHJvYmxlbSBhbmQg DQogIHlvdSB3b3VsZCZuYnNwO25vdCBwaWNrIHVwIHRoZSBjYWxsJm5ic3A7YW5kIHlvdSBtaWdo dCByZXBvcnQgdGhlIGNhbGwgdG8gdGhlIA0KICBhcHByb3ByaWF0ZSBhdXRob3JpdGllcyB3aG8g Y291bGQgdGhlbiB0cmFjZSB0aGUgY2FsbCBwb3RlbnRhaWxseS48L1A+DQogIDxQPlF1aXRlIGhv dyB0aGlzIGNvcnJlbGF0aW9uIHRha2VzIHBsYWNlIGlzIG5vdCAxMDAlIGNsZWFyIHRvIG1lIGFz IHlldCwgYnV0IA0KICBJJ20gdGhpbmtpbmcgb24gaXQuPEJSPjwvUD4NCiAgPFA+VG9ueSZuYnNw OyZuYnNwOzxCUj48QlI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBweCI+VGhpcyBpcyBhIFBS SVZBVEUgDQogIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBkZWxldGUgd2l0aG91dCBjb3B5aW5nIA0KICBhbmQga2luZGx5IGFkdmlzZSB1cyBi eSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIDxCUj5OT1RFOiANCiAgUmVnYXJk bGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kIENT QyB0byBhbnkgb3JkZXIgDQogIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBl eHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IA0KICBpbml0aWF0aXZlIGV4 cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzdWNoIA0KICBwdXJwb3Nl LjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4Ij4mbmJzcDvigKImbmJzcDs8L1NQ QU4+PC9QPg0KICA8RElWPjxCUj48L0RJVj48Rk9OVCBjb2xvcj0jOTkwMDk5Pi0tLS0tc2lwLWJv dW5jZXNAaWV0Zi5vcmcgd3JvdGU6IA0KICAtLS0tLTxCUj48QlI+PC9GT05UPg0KICA8QkxPQ0tR VU9URSANCiAgc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1B UkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJ R0hUOiAwcHgiPlRvOiANCiAgICAiSm9uIFBldGVyc29uIiAmbHQ7am9uLnBldGVyc29uQG5ldXN0 YXIuYml6Jmd0OywgIkVsd2VsbCwgSm9obiIgDQogICAgJmx0O2pvaG4uZWx3ZWxsQHNpZW1lbnMt ZW50ZXJwcmlzZS5jb20mZ3Q7LCAiRGVhbiBXaWxsaXMiIA0KICAgICZsdDtkZWFuLndpbGxpc0Bz b2Z0YXJtb3IuY29tJmd0OzxCUj5Gcm9tOiAiRnJhbmNvaXMgQXVkZXQiIA0KICAgICZsdDthdWRl dEBub3J0ZWwuY29tJmd0OzxCUj5TZW50IGJ5OiBzaXAtYm91bmNlc0BpZXRmLm9yZzxCUj5EYXRl OiANCiAgICAwNC8xMC8yMDA5IDA0OjQzUE08QlI+Y2M6IEN1bGxlbiBKZW5uaW5ncyAmbHQ7Zmx1 ZmZ5QGNpc2NvLmNvbSZndDssIA0KICAgIHNpcEBpZXRmLm9yZywgIkRSQUdFLCBLZWl0aCBcKEtl aXRoXCkiIA0KICAgICZsdDtkcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7PEJSPlN1YmplY3Q6 IFJlOiBbU2lwXSBmcmFuY29pcycgY29tbWVudHMgDQogICAgYW5kIHdoeSBSRkM0NDc0IG5vdCB1 c2VkIGluIHRoZSBmaWVsZDxCUj48QlI+PEZPTlQgDQogICAgZmFjZT0iRGVmYXVsdCBNb25vc3Bh Y2UsQ291cmllciBOZXcsQ291cmllcixtb25vc3BhY2UiIHNpemU9Mj5SaWdodCwgdGhlIA0KICAg IHNpZ25hbGxpbmcgZ2V0cyBpbXBlcnNvbmF0ZWQsIGJ1dCBub3QgdGhlIG1lZGlhLjxCUj48QlI+ U28gdGhlIG9ubHkgDQogICAgcHJhY3RpY2FsIHRoaW5nIHRoYXQgY2FuIGJlIGRvbmUgYnkgdGhl IGF0dGFja2VyPEJSPmlzIGludGVydXAgbWVkaWEuIA0KICAgIDxCUj48QlI+Jmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7IEZyb206IEpvbiBQZXRlcnNvbiBbPEEgDQogICAg aHJlZj0ibWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpeiIgDQogICAgdGFyZ2V0PWJsYW5r Pm1haWx0bzpqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXo8L0E+XSA8QlI+Jmd0OyBTZW50OiBGcmlk YXksIA0KICAgIEFwcmlsIDEwLCAyMDA5IDEyOjI4PEJSPiZndDsgVG86IEF1ZGV0LCBGcmFuY29p cyAoU0MxMDA6MzA1NSk7IEVsd2VsbCwgSm9objsgDQogICAgRGVhbiBXaWxsaXM8QlI+Jmd0OyBD YzogQ3VsbGVuIEplbm5pbmdzOyBzaXBAaWV0Zi5vcmc7IERSQUdFLEtlaXRoIA0KICAgIChLZWl0 aCk8QlI+Jmd0OyBTdWJqZWN0OiBSZTogW1NpcF0gZnJhbmNvaXMnIGNvbW1lbnRzIGFuZCB3aHkg UkZDNDQ3NCBub3QgDQogICAgPEJSPiZndDsgdXNlZCBpbiB0aGUgZmllbGQ8QlI+Jmd0OyA8QlI+ Jmd0OyBJZiBJIG1heSBxdWliYmxlIGhlcmU6PEJSPiZndDsgDQogICAgPEJSPiZndDsgJmd0OyBU aGUgYXR0YWNrIGlzIG5vdCBpbXBlcnNvbmF0aW9uLCBpdCdzIGludGVycnVwdGlvbiBvZiANCiAg ICBtZWRpYS48QlI+Jmd0OyA8QlI+Jmd0OyBUaGUgYXR0YWNrIHJlbGllcyBvbiBpbXBlcnNvbmF0 aW9uIHRvIGFjY29tcGxpc2ggDQogICAgaW50ZXJydXB0aW9uIDxCUj4mZ3Q7IG9mIG1lZGlhLiBU aGUgYXR0YWNrZXIgbGlzdGVucyB0byBBbGljZSdzIElOVklURSwgYW5kIA0KICAgIHRoZW4gPEJS PiZndDsgc2VuZHMgYSBjdXQtYW5kLXBhc3RlZCByZS1JTlZJVEUgc2F5aW5nICJUaGlzIGlzIEFs aWNlIGFnYWluLCANCiAgICA8QlI+Jmd0OyB3b3VsZCB5b3UgbWluZCBzZW5kaW5nIG15IG1lZGlh IGhlcmUgaW5zdGVhZCBwbGVhc2UuIiA8QlI+Jmd0OyANCiAgICBJbXBlcnNvbmF0aW9uIGlzIGFs bW9zdCBhbHdheXMgYSB0b29sIHRoYXQgYXR0YWNrZXJzIHVzZSB0byA8QlI+Jmd0OyANCiAgICBh Y2NvbXBsaXNoIHNvbWUgcGFydGljdWxhciBnb2FsLCBldmVuIGlmIGl0J3MganVzdCB0cmlja2lu ZyA8QlI+Jmd0OyB5b3UgDQogICAgaW50byBhY2NlcHRpbmcgdW53YW50ZWQgY29tbXVuaWNhdGlv bnMuIEknbSBub3Qgc3VyZSBJJ2QgPEJSPiZndDsgc2F5IA0KICAgIGltcGVyc29uYXRpb24gaXMg YW4gYXR0YWNrIGFzIHN1Y2gsIGJ1dCBieSBwcmV2ZW50aW5nIGl0LCA8QlI+Jmd0OyB3ZSANCiAg ICBwcmV2ZW50IHdob2xlIGNhdGVnb3JpZXMgb2YgYXR0YWNrcyBhbmQgZ3JhbnQgb3Vyc2VsdmVz IDxCUj4mZ3Q7IG1vcmUgcG93ZXJzIA0KICAgIGluIGNyYWZ0aW5nIGF1dGhvcml6YXRpb24gDQog ICAgcG9saWNpZXMuPEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPEJSPlNpcCBtYWlsaW5nIA0KICAgIGxpc3QgJm5ic3A7PEEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAiIA0KICAgIHRhcmdldD1ibGFuaz5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcDwvQT48QlI+VGhpcyBsaXN0IGlz IA0KICAgIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sPEJSPlVz ZSANCiAgICBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9u IGN1cnJlbnQgc2lwPEJSPlVzZSANCiAgICBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxv cG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiANCiAgc2lwPEJSPjwvRk9OVD48L0JMT0NLUVVP VEU+PEJSPjwvQkxPQ0tRVU9URT48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C9BC51.4E88BD08-- From apike3@csc.com Mon Apr 13 09:09:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384CB3A677C for ; Mon, 13 Apr 2009 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.691 X-Spam-Level: X-Spam-Status: No, score=-4.691 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_55=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy+crVi75LyJ for ; Mon, 13 Apr 2009 09:09:29 -0700 (PDT) Received: from mail168.messagelabs.com (mail168.messagelabs.com [216.82.253.195]) by core3.amsl.com (Postfix) with ESMTP id F05093A6DF9 for ; Mon, 13 Apr 2009 09:09:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: apike3@csc.com X-Msg-Ref: server-2.tower-168.messagelabs.com!1239639037!7105840!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 31589 invoked from network); 13 Apr 2009 16:10:38 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-2.tower-168.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Apr 2009 16:10:38 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n3DGAbpA013378; Mon, 13 Apr 2009 12:10:37 -0400 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D649A2D@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1D5F2B8B@zrc2hxm0.corp.nortel.com> , <1ECE0EB50388174790F9694F77522CCF1D649045@zrc2hxm0.corp.nortel.com> , <1ECE0EB50388174790F9694F77522CCF1D649A2D@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 From: Anthony D Pike To: "Audet, Francois (SC100:3055)" Message-ID: Date: Mon, 13 Apr 2009 12:10:32 -0400 X-Mailer: Lotus Domino Web Server Release 8.0.1 February 07, 2008 X-MIMETrack: Serialize by Notes Server on AMER-ML20/SRV/CSC(Release 8.0.1|February 07, 2008) at 04/13/2009 12:10:32, Serialize complete at 04/13/2009 12:10:33, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 04/13/2009 12:12:42 PM MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" , Jon Peterson , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 16:09:30 -0000

Hi

interruptions in a media stream may occur naturally in the= network for many reasons!

My point was to emphasize that i= f you don't correlate signalling with the original media stream(s)&nbs= p;from the calling user, then the called user cannot truely authentica= te the caller. This should be a requirement? How to correlate the signallin= g with the media streams is TBD.

Tony

  

This is a PRIVATE message. If you are not the in= tended recipient, please delete without copying and kindly advise us by e-m= ail of the mistake in delivery.
NOTE: Regardless of content, this e-mai= l shall not operate to bind CSC to any order or other contract unless pursu= ant to explicit written agreement or government initiative expressly permit= ting the use of e-mail for such purpose. =E2=80=A2 


--= ---"Audet, Francois (SC100:3055)" <AUDET@nortel.com> wrote: -----
=
To: Anthon= y D Pike/ESI/CSC@CSC
From: "Audet, Francois (SC100:3055)" <AUDET@nort= el.com>
Date: 04/13/2009 12:02PM
cc: "Cullen Jennings" <fluffy@= cisco.com>, "Jon Peterson" <jon.peterson@neustar.biz>, <sip@iet= f.org>, "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, "Dean W= illis" <dean.willis@softarmor.com>
Subject: RE: [Sip] francois' co= mments and why RFC4474 not used in the field

=EF=BB=BF
I agree.
=
<= /DIV>
I think the= issue Jon is pointing out is that one could interrupt the media stream.

From: sip-bounces@ietf.org [mailto:sip-bounce= s@ietf.org] On Behalf Of Anthony D Pike
Sent: Monday, Apr= il 13, 2009 06:16
To: Audet, Francois (SC100:3055)
Cc: Cullen Jennings; Jon Peterson; sip@ietf.org; DRAGE, Keith (Keith); Dean W= illis
Subject: Re: [Sip] francois' comments and why RFC4474 not = used in the field

 

hi Francios, =

Surely if you correlate the signallng with the initial media st= ream from the endpoint as Jonathan mentioned in his original email a c= ouple of weeks ago then you will know that that there has been a problem an= d you would not pick up the call and you might report the call to= the appropriate authorities who could then trace the call potentailly.

Quite how this correlation takes place is not 100% clear to me as yet, = but I'm thinking on it.

Tony  

This is a PRIVATE message. If you are not the intended rec= ipient, please delete without copying and kindly advise us by e-mail of the= mistake in delivery.
NOTE: Regardless of content, this e-mail shall no= t operate to bind CSC to any order or other contract unless pursuant to exp= licit written agreement or government initiative expressly permitting the u= se of e-mail for such purpose.  = ;=E2=80=A2 


-----sip-b= ounces@ietf.org wrote: -----

To: "Jon Peterson" <jon.peterson@neustar.biz>,= "Elwell, John" <john.elwell@siemens-enterprise.com>, "Dean Willis" &= lt;dean.willis@softarmor.com>
From: "Francois Audet" <audet@norte= l.com>
Sent by: sip-bounces@ietf.org
Date: 04/10/2009 04:43PM cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org, "DRAGE, Keith= \(Keith\)" <drage@alcatel-lucent.com>
Subject: Re: [Sip] francoi= s' comments and why RFC4474 not used in the field

Right, the signallin= g gets impersonated, but not the media.

So the only practical thing= that can be done by the attacker
is interup media.

> -----O= riginal Message-----
> From: Jon Peterson [ mailto:jon.peterson@neustar.biz ] > Sent: Friday, April 10, 2009 12:28
> To: Audet, Francois (SC1= 00:3055); Elwell, John; Dean Willis
> Cc: Cullen Jennings; sip@ietf.= org; DRAGE,Keith (Keith)
> Subject: Re: [Sip] francois' comments and= why RFC4474 not
> used in the field
>
> If I may quib= ble here:
>
> > The attack is not impersonation, it's inte= rruption of media.
>
> The attack relies on impersonation to = accomplish interruption
> of media. The attacker listens to Alice's = INVITE, and then
> sends a cut-and-pasted re-INVITE saying "This is = Alice again,
> would you mind sending my media here instead please."=
> Impersonation is almost always a tool that attackers use to
&= gt; accomplish some particular goal, even if it's just tricking
> yo= u into accepting unwanted communications. I'm not sure I'd
> say imp= ersonation is an attack as such, but by preventing it,
> we prevent = whole categories of attacks and grant ourselves
> more powers in cra= fting authorization policies.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
Sip mailing list   https://www.ietf.org/mail= man/listinfo/sip
This list is for NEW development of the core SIP P= rotocol
Use sip-implementors@cs.columbia.edu for questions on current s= ip
Use sipping@ietf.org for new developments on the application of sip =


= From AUDET@nortel.com Mon Apr 13 09:11:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E41D3A6DC0 for ; Mon, 13 Apr 2009 09:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuFUYkX2jrZN for ; Mon, 13 Apr 2009 09:11:07 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id EBABC3A6E9B for ; Mon, 13 Apr 2009 09:10:39 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3DGB7Q01049; Mon, 13 Apr 2009 16:11:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BC52.89E3A74A" Date: Mon, 13 Apr 2009 11:11:43 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D649A77@zrc2hxm0.corp.nortel.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D675883EFE@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Clarification on RFC 4458: SIP URIs for Applications suchas Voicemail and Interactive Voice Response (IVR) Thread-Index: Acm5syte6sKHPhvzSIuIQB0ZVQL2nQAiCKIgAIWPj3A= References: <28B7C3AA2A7ABA4A841F11217ABE78D6758486E4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <9ae56b1e0904100105i351ff961wf9afac4b08938cee@mail.gmail.com> <28B7C3AA2A7ABA4A841F11217ABE78D675883EFE@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Francois Audet" To: "DRAGE, Keith (Keith)" , "Hans Erik van Elburg" Cc: sip@ietf.org, Cullen Jennings , "Elwell, John" Subject: Re: [Sip] Clarification on RFC 4458: SIP URIs for Applications suchas Voicemail and Interactive Voice Response (IVR) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 16:11:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BC52.89E3A74A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What we had in mind when writting this was the equivalent to the Q.931 = Redirecting Number information element (and whatever it's ISUP = equivalent is, or even Diversion header for that matter). =20 The target maps to the Number digits (which is always there), and the = cause maps to the "Reason for redirection,octet 3b", which is optional. = Absence means the reason is unknown. I would say that if cause is not there, then it means the same as cause=3D404. =20 Also, if target is not there, I guess it means that the number is not = known.=20 =20 But you are right, I don't believe the text in 4458 explains it = properly. ________________________________ From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Friday, April 10, 2009 17:45 To: Hans Erik van Elburg Cc: sip@ietf.org; Cullen Jennings; Audet, Francois (SC100:3055); = Elwell, John Subject: RE: [Sip] Clarification on RFC 4458: SIP URIs for Applications = suchas Voicemail and Interactive Voice Response (IVR) =09 =09 And which part of the wording in RFC 4458 do you use to justify that? =20 The whole point of the question is that we are trying to ascertain what = is a legitimate conformance with RFC 4458. =20 regards =20 Keith ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Hans Erik van Elburg Sent: Friday, April 10, 2009 9:06 AM To: DRAGE, Keith (Keith) Cc: sip@ietf.org; Cullen Jennings; Francois Audet; Elwell, John Subject: Re: [Sip] Clarification on RFC 4458: SIP URIs for = Applications such as Voicemail and Interactive Voice Response (IVR) =09 =09 Specifications that only include the cause value mappings as specified = in RFC4458 reuse only that part of RFC4458.=20 =09 Such reuse is of course fine, but carefull wording is required not to = imply full conformance with RFC4458 as that would lead to the wrong = implications/expectations. =09 /Hans Erik van Elburg =09 =09 =09 On Wed, Apr 8, 2009 at 6:06 PM, DRAGE, Keith (Keith) = wrote: =09 RFC 4458 defines two SIP URI parameters. =09 I can find no specific language in the document that indicates = whether these two URI parameters can be used independently of each = other, or whether there is an expectation that both URI parameters = should only exist in the presence of each other. Specifically does an = implementation that only includes the "cause" SIP URI parameter and not = the "target" sip URI parameter conform to this specification? =09 All the text and examples seem to carry the implication that where = one exists, the other one will also. =09 Could one of the authors or some other interested party clarify what = they believe the intention is? =09 regards =09 Keith _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C9BC52.89E3A74A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What=20 we had in mind when writting this was the equivalent to the Q.931 = Redirecting=20 Number information element (and whatever it's ISUP equivalent is, or = even=20 Diversion header for that matter).
 
The=20 target maps to the Number digits (which is always there), and the cause = maps to=20 the "Reason for redirection,octet 3b", which is optional. Absence means = the=20 reason is unknown. I would say that if cause is
not=20 there, then it means the same as cause=3D404.
 
Also,=20 if target is not there, I guess it means that the number is not known.=20
 
But=20 you are right, I don't believe the text in 4458 explains it=20 properly.

From: DRAGE, Keith (Keith)=20 [mailto:drage@alcatel-lucent.com]
Sent: Friday, April 10, = 2009=20 17:45
To: Hans Erik van Elburg
Cc: sip@ietf.org; = Cullen=20 Jennings; Audet, Francois (SC100:3055); Elwell, = John
Subject: RE:=20 [Sip] Clarification on RFC 4458: SIP URIs for Applications suchas = Voicemail=20 and Interactive Voice Response (IVR)

And which part of the wording in RFC 4458 do = you use to=20 justify that?
 
The whole point of the question is that we = are trying to=20 ascertain what is a legitimate conformance with RFC = 4458.
 
regards
 
Keith

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van=20 Elburg
Sent: Friday, April 10, 2009 9:06 AM
To: = DRAGE,=20 Keith (Keith)
Cc: sip@ietf.org; Cullen Jennings; Francois = Audet;=20 Elwell, John
Subject: Re: [Sip] Clarification on RFC 4458: = SIP=20 URIs for Applications such as Voicemail and Interactive Voice = Response=20 (IVR)

Specifications that only include the cause value mappings = as=20 specified in RFC4458 reuse only that part of RFC4458.

Such = reuse is=20 of course fine, but carefull wording is required not to imply full=20 conformance with RFC4458 as that would lead to the wrong=20 implications/expectations.

/Hans Erik van=20 Elburg


On Wed, Apr 8, 2009 at 6:06 PM, DRAGE, = Keith (Keith)=20 <drage@alcatel-lucent.com>= =20 wrote:
RFC=20 4458 defines two SIP URI parameters.

I can find no specific = language in the document that indicates whether these two URI = parameters=20 can be used independently of each other, or whether there is an=20 expectation that both URI parameters should only exist in the = presence of=20 each other. Specifically does an implementation that only includes = the=20 "cause" SIP URI parameter and not the "target" sip URI parameter = conform=20 to this specification?

All the text and examples seem to = carry the=20 implication that where one exists, the other one will = also.

Could=20 one of the authors or some other interested party clarify what = they=20 believe the intention=20 = is?

regards

Keith
______________________________________= _________
Sip=20 mailing list  https://www.ietf.org/mailman/listinfo/sip
This = list=20 is for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments=20 on the application of=20 sip

------_=_NextPart_001_01C9BC52.89E3A74A-- From AUDET@nortel.com Mon Apr 13 09:11:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0553A6E9E for ; Mon, 13 Apr 2009 09:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygQLp0s-D4yO for ; Mon, 13 Apr 2009 09:11:41 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0E1A53A677C for ; Mon, 13 Apr 2009 09:11:39 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3DGCKM03430; Mon, 13 Apr 2009 16:12:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BC52.9E7B1698" Date: Mon, 13 Apr 2009 11:12:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D649A83@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm8Um6qEyYmQhxdTfexJMeSUxaS/QAACocQ References: <1ECE0EB50388174790F9694F77522CCF1D5F2B8B@zrc2hxm0.corp.nortel.com> , <1ECE0EB50388174790F9694F77522CCF1D649045@zrc2hxm0.corp.nortel.com>, <1ECE0EB50388174790F9694F77522CCF1D649A2D@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Anthony D Pike" Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" , Jon Peterson , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 16:11:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BC52.9E7B1698 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoJRnJvbTog c2lwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEFudGhvbnkgRCBQaWtlDQoJU2VudDogTW9uZGF5LCBBcHJpbCAxMywgMjAwOSAwOTox MQ0KCVRvOiBBdWRldCwgRnJhbmNvaXMgKFNDMTAwOjMwNTUpDQoJQ2M6IEN1bGxlbiBKZW5uaW5n czsgc2lwQGlldGYub3JnOyBEUkFHRSxLZWl0aCAoS2VpdGgpOyBKb24gUGV0ZXJzb247IERlYW4g V2lsbGlzDQoJU3ViamVjdDogUmU6IFtTaXBdIGZyYW5jb2lzJyBjb21tZW50cyBhbmQgd2h5IFJG QzQ0NzQgbm90IHVzZWQgaW4gdGhlIGZpZWxkDQoJDQoJDQoJSGkNCg0KCWludGVycnVwdGlvbnMg aW4gYSBtZWRpYSBzdHJlYW0gbWF5IG9jY3VyIG5hdHVyYWxseSBpbiB0aGUgbmV0d29yayBmb3Ig bWFueSByZWFzb25zIQ0KDQoJTXkgcG9pbnQgd2FzIHRvIGVtcGhhc2l6ZSB0aGF0IGlmIHlvdSBk b24ndCBjb3JyZWxhdGUgc2lnbmFsbGluZyB3aXRoIHRoZSBvcmlnaW5hbCBtZWRpYSBzdHJlYW0o cykgZnJvbSB0aGUgY2FsbGluZyB1c2VyLCB0aGVuIHRoZSBjYWxsZWQgdXNlciBjYW5ub3QgdHJ1 ZWx5IGF1dGhlbnRpY2F0ZSB0aGUgY2FsbGVyLiBUaGlzIHNob3VsZCBiZSBhIHJlcXVpcmVtZW50 PyBIb3cgdG8gY29ycmVsYXRlIHRoZSBzaWduYWxsaW5nIHdpdGggdGhlIG1lZGlhIHN0cmVhbXMg aXMgVEJELg0KDQoJVG9ueQ0KDQoJICANCgkNCg0K ------_=_NextPart_001_01C9BC52.9E7B1698 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxTUEFO IGNsYXNzPTMyNjA5MTIxNi0xMzA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4MDAwMDAg c2l6ZT0yPkkgDQphZ3JlZS48L0ZPTlQ+PC9TUEFOPjwvRElWPjxCUj4NCjxCTE9DS1FVT1RFIA0K c3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDog IzgwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1PdXRs b29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhSIHRh YkluZGV4PS0xPg0KICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IHNpcC1i b3VuY2VzQGlldGYub3JnIA0KICBbbWFpbHRvOnNpcC1ib3VuY2VzQGlldGYub3JnXSA8Qj5PbiBC ZWhhbGYgT2YgPC9CPkFudGhvbnkgRCANCiAgUGlrZTxCUj48Qj5TZW50OjwvQj4gTW9uZGF5LCBB cHJpbCAxMywgMjAwOSAwOToxMTxCUj48Qj5Ubzo8L0I+IEF1ZGV0LCANCiAgRnJhbmNvaXMgKFND MTAwOjMwNTUpPEJSPjxCPkNjOjwvQj4gQ3VsbGVuIEplbm5pbmdzOyBzaXBAaWV0Zi5vcmc7IERS QUdFLEtlaXRoIA0KICAoS2VpdGgpOyBKb24gUGV0ZXJzb247IERlYW4gV2lsbGlzPEJSPjxCPlN1 YmplY3Q6PC9CPiBSZTogW1NpcF0gZnJhbmNvaXMnIA0KICBjb21tZW50cyBhbmQgd2h5IFJGQzQ0 NzQgbm90IHVzZWQgaW4gdGhlIGZpZWxkPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogIDxESVY+PC9E SVY+PEZPTlQgZmFjZT0iRGVmYXVsdCBTYW5zIFNlcmlmLFZlcmRhbmEsQXJpYWwsSGVsdmV0aWNh LHNhbnMtc2VyaWYiIA0KICBzaXplPTI+DQogIDxQPkhpPC9QPg0KICA8UD5pbnRlcnJ1cHRpb25z IGluIGEgbWVkaWEgc3RyZWFtIG1heSBvY2N1ciBuYXR1cmFsbHkgaW4gdGhlIG5ldHdvcmsgZm9y IG1hbnkgDQogIHJlYXNvbnMhPC9QPg0KICA8UD5NeSBwb2ludCB3YXMmbmJzcDt0byZuYnNwO2Vt cGhhc2l6ZSB0aGF0IGlmIHlvdSBkb24ndCBjb3JyZWxhdGUgc2lnbmFsbGluZyANCiAgd2l0aCZu YnNwO3RoZSBvcmlnaW5hbCBtZWRpYSBzdHJlYW0ocykmbmJzcDtmcm9tIHRoZSBjYWxsaW5nIHVz ZXIsIA0KICB0aGVuJm5ic3A7dGhlIGNhbGxlZCB1c2VyIGNhbm5vdCB0cnVlbHkgYXV0aGVudGlj YXRlIHRoZSBjYWxsZXIuIFRoaXMgc2hvdWxkIA0KICBiZSBhIHJlcXVpcmVtZW50PyBIb3cgdG8g Y29ycmVsYXRlIHRoZSBzaWduYWxsaW5nIHdpdGggdGhlIG1lZGlhIHN0cmVhbXMgaXMgDQogIFRC RC48L1A+DQogIDxQPlRvbnk8L1A+DQogIDxQPiZuYnNwOyZuYnNwOzxCUj48L1A+PC9CTE9DS1FV T1RFPjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C9BC52.9E7B1698-- From jon.peterson@neustar.biz Mon Apr 13 10:17:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06F728C124 for ; Mon, 13 Apr 2009 10:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 k+NO3-Zhc7Ak for ; Mon, 13 Apr 2009 10:17:51 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 76FC428C122 for ; Mon, 13 Apr 2009 10:17:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1239643139; x=1239729539; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=R1XT5Q36bAlOrPj3qoc3vnemnao/tCjdsMBB65zIduyWrYH87usALr/5iNu/X6W5MiZvnumhZm1B1b X5gr6tVQ== Received: from ([10.31.13.50]) by chihiron1.nc.neustar.com with ESMTP id 5202942.15117085; Mon, 13 Apr 2009 13:18:47 -0400 Received: from 10.31.13.114 ([10.31.13.114]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Apr 2009 17:18:47 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 13 Apr 2009 10:18:47 -0700 From: Jon Peterson To: "Elwell, John" , Francois Audet , Dean Willis Message-ID: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sAKwvW0ABuPjkl In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001C1EDDB@GBNTHT12009MSX.gb002.siemens.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 17:17:51 -0000 I am saying that there solutions that have those properties that would be satisfactory from my perspective, yes, but certainly not that a solution must exhibit these properties. Obviously something like using TURN and having the originating administrative domain sign the IP/port generated by the intermediary is also fine with me, for example. Jon Peterson NeuStar, Inc. On 4/11/09 5:46 AM, "Elwell, John" wrote: > Jon, > > So a consequence of what you are saying is that to verify who you are > negotiating DTLS-SRTP security with you need one signature, covering the > certificate fingerprint and sufficient other stuff to prevent replay, and to > verify which intermediary told you the IP address and port to send media to > you need a second signature. Correct? > > John From dwing@cisco.com Mon Apr 13 10:37:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63A4D3A69AE for ; Mon, 13 Apr 2009 10:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.033 X-Spam-Level: X-Spam-Status: No, score=-6.033 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtfjnD6O1IWJ for ; Mon, 13 Apr 2009 10:37:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E81CE3A6A47 for ; Mon, 13 Apr 2009 10:37:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,180,1238976000"; d="scan'208";a="170837206" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 13 Apr 2009 17:38:51 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3DHco4N008910; Mon, 13 Apr 2009 10:38:50 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3DHcond010419; Mon, 13 Apr 2009 17:38:50 GMT From: "Dan Wing" To: "'Jon Peterson'" , "'Francois Audet'" , "'Elwell, John'" , "'Dean Willis'" References: <1ECE0EB50388174790F9694F77522CCF1D5F2B8B@zrc2hxm0.corp.nortel.com> Date: Mon, 13 Apr 2009 10:38:50 -0700 Message-ID: <009d01c9bc5e$b5395170$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sABO07UAACAyOlAJLdPdA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11104; t=1239644331; x=1240508331; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=6EoVhl4W8DTLPt4WZJohcegy8PiI1i3mganuowQCJ6Y=; b=hV4A59aiREAGaa6td/BixL5bauN80ueSn5VdeWVuwwDS2Y9b3kIX4CcjgU 0yIJIMa5rqmccWJW9Qf2Jk+jXQoltsur6mEARpIG1YHR+qgrg+hR5Vm+qRMz 44AcziNhwO; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Cullen Jennings' , sip@ietf.org, "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 17:37:41 -0000 =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Jon Peterson > Sent: Friday, April 10, 2009 12:28 PM > To: Francois Audet; Elwell, John; Dean Willis > Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 > If I may quibble here: >=20 > > The attack is not impersonation, it's interruption of media. >=20 > The attack relies on impersonation to accomplish interruption=20 > of media. The > attacker listens to Alice's INVITE, and then sends a cut-and-pasted > re-INVITE saying "This is Alice again, would you mind sending=20 > my media here > instead please." The 'Alice again' attacker would need to prove Alice's identity which=20 the attacker cannot accomplish (unless the attacker knows Alice's=20 private key). This is true of RFC4474 and=20 draft-fischer-sip-e2e-sec-media and draft-wing-sip-identity-media. All three of those require the attacker to sign SIP headers and, in the case of the two I-D's, the attacker has to also perform a handshake proving possession of Alice's private key. I don't see the new attack that you are seeing. -d > Impersonation is almost always a tool that=20 > attackers use to > accomplish some particular goal, even if it's just tricking you into > accepting unwanted communications. I'm not sure I'd say=20 > impersonation is an > attack as such, but by preventing it, we prevent whole=20 > categories of attacks > and grant ourselves more powers in crafting authorization policies. >=20 > Jon Peterson > NeuStar, Inc. >=20 > On 4/10/09 11:37 AM, "Francois Audet" wrote: >=20 > > Yes, this makes sense to me. > >=20 > > The attack is not impersonnation, it's interuption of media. > >=20 > > Verifying the address of the relay seems difficult to me. It could > > be in source domain, destination domain, some intermediary. Or there > > could even be more than one. Unless we do it hop by hop. > >=20 > > I guess we could have another layer of TLS exchange between the > > UA and the intermediary (where instead of a self-signed cert, > > you would actually autenticate your intermediary). Wouldn't do > > wonders for backward compatibility however, and I'm not sure > > it would be simpler than TURN. > >=20 > >> -----Original Message----- > >> From: Jon Peterson [mailto:jon.peterson@neustar.biz] > >> Sent: Friday, April 10, 2009 09:10 > >> To: Audet, Francois (SC100:3055); Elwell, John; Dean Willis > >> Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > >> Subject: Re: [Sip] francois' comments and why RFC4474 not > >> used in the field > >>=20 > >>=20 > >> At a high level, when an intermediary is going to relay your > >> media, the intermediary (not the UAC) is the source of the > >> IP/port data that appears in SDP, and as such, I can accept > >> alternatives to securing that data with a signature from the > >> originating administrative domain (abstractly, that goes > >> equally for SBCs and TURN, I suppose). I don't however > >> believe it follows from this that it just doesn't matter at > >> all who sets the IP/port data in SDP. I think it does matter, > >> and it matters most when we consider approaches that defer > >> security checks from the SIP layer to the media layer. For > >> example, if relatively weak SIP-layer security facilitates > >> cut-and-paste attacks, then an eavesdropper could listen to > >> INVITEs, forge re-INVITEs with the same signature but set the > >> IP/port to something unhelpful, and methodically tear down a > >> target's calls five seconds after they start. So from my > >> perspective, verifying the origin of IP/port data still has > >> value, even if the origin of that data is not the originating > >> administrative domain. > >>=20 > >> Jon Peterson > >> NeuStar, Inc. > >>=20 > >>=20 > >> On 4/9/09 12:09 PM, "Francois Audet" wrote: > >>=20 > >>> So, at a high level, if we could "sign the blob" =E0-la-RFC=20 > 4474, but > >>> exclude very specific elements (i.e., the IP:port), and combine it > >>> with DTLS-SRTP (or TLS for non-real time media), in specific cases > >>> where allowing Media Relays is desireable/necessary, then > >> we may have=20 > >>> a solution, right? > >>>=20 > >>> I'm interpreting your email as we should have an opt-out of > >> integrity=20 > >>> protection (carefully used) instead of an opt-in (as per the > >>> draft-wing-identity-media draft). > >>>=20 > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: Jon Peterson [mailto:jon.peterson@neustar.biz] > >>>> Sent: Thursday, April 09, 2009 11:50 > >>>> To: Elwell, John; Audet, Francois (SC100:3055); Dean Willis > >>>> Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith) > >>>> Subject: Re: [Sip] francois' comments and why RFC4474 not > >> used in the=20 > >>>> field > >>>>=20 > >>>>=20 > >>>>> [JRE] If media is encrypted, sending it to the wrong IP > >>>> address/port, > >>>>> whilst it will cause the call to fail, will not reveal the > >>>> information > >>>>> to the recipient. Of course, if media is not encrypted, > >>>> that has worse > >>>>> consequences, but unencrypted media can be eavesdropped by other > >>>>> mechanisms, or can be spoofed or modified. Knowing who told > >>>> you which > >>>>> IP address/port to send to only gives you a certain amount > >>>> of protection. > >>>>> We must ensure we do not lower the security available when > >>>> encryption > >>>>> is in use (losing the ability to authenticate the user we > >> performed=20 > >>>>> key agreement with) by clinging on to mechanisms that give > >>>> some minor > >>>>> benefit to the unencrypted case. > >>>>=20 > >>>> In fairness, I don't think the choice is between signing > >> the IP/port=20 > >>>> and not signing the IP/port. It is between signing the=20 > entire MIME > >>>> body as a blob the auth service does not have to > >> understand, versus > >>>> selecting a set of elements (understood here not to include the > >>>> IP/port) and signing those exclusively. If we want to > >> understand the=20 > >>>> benefits of the former approach, they go a bit beyond > >> protecting the=20 > >>>> IP/port. > >>>> Architecturally, signing the blob results in better future > >>>> compatibility and better paths to extending SDP. If the > >>>> authentication service needs to know what elements in SDP > >> are to be=20 > >>>> included in the signature, then the authentication service > >> behavior=20 > >>>> needs to change every time that clients start using SDP > >> (or bodies,=20 > >>>> for that > >>>> matter) in new ways. > >>>>=20 > >>>> If someone wakes up tomorrow, invents a new media security > >> model, and=20 > >>>> decides there is value in having an indicator in SDP=20 > that will let > >>>> you correlate the rendezvous layer with media security > >> keying, under=20 > >>>> the blob model that indicator can just get stuck in SDP, and the > >>>> authentication service does not need to change its > >> behavior in order > >>>> to sign it. > >>>> Taking this to its extreme, while I'm sure no one would > >> stand up to=20 > >>>> defend SDPng these days, virtually everyone would say that > >> SDP isn't=20 > >>>> the ideal tool for establishing complicated sessions; if > >> we ever do=20 > >>>> get around to building something better, the > >> authentication service > >>>> in the blob signature model shouldn't need to understand > >> it. This is,=20 > >>>> again, just a basic SIP layering architecture we've always > >> followed,=20 > >>>> intended to maximize the ability of endpoints to innovate > >> and reduce=20 > >>>> the brittleness of intermediaries. > >>>>=20 > >>>> Even without looking to the future, I think there's > >> reasonable value > >>>> in signing most of the cruft in SDP. For example, as I've > >> mentioned=20 > >>>> before, I think it's worth detecting various codec > >> downgrade sorts of > >>>> attacks. But speaking to the IP/port again specifically, I > >> maintain=20 > >>>> that when sending media doesn't work, it is useful for UAS to > >>>> ascertain who set the target IP/port, and if the IP/port > >> shouldn't be=20 > >>>> tried anyway because they were inserted by an attacker, I > >> think it's=20 > >>>> useful for the UAS to know that before it processes that > >> re-INVITE,=20 > >>>> or begins altering for that initial INVITE, or what have you. > >>>>=20 > >>>>>> broadly I > >>>>>> think it doesn't address threats where an > >>>> attacker/impersonator can > >>>>>> accomplish their goals without ever establishing a > >> session. If we=20 > >>>>>> think about, I suspect we'll find there are actually quite > >>>> a few of those. > >>>>> [JRE] So this suggests the need for two solutions: one for > >>>> protecting > >>>>> the rendez-vous layer and one for protecting the media=20 > layer. The > >>>>> problem is that the mechanism for protecting the > >> rendez-vous layer > >>>>> (RFC > >>>>> 4474) does not work in certain deployment situations, and > >>>> because we > >>>>> reuse that for authenticating the media layer (using it > >> to sign the=20 > >>>>> fingerprint of the certificate used at the media layer) we > >>>> are unable > >>>>> to have protection of the media layer in those deployment > >>>> situations. > >>>>=20 > >>>> Certainly I agree that RFC4474 interprets "certain deployment > >>>> situations" as security violations, and that is a > >> limitation of its > >>>> approach. I was merely pointing out that there are also > >> limitations=20 > >>>> to an approach where we largely defer security to the=20 > media layer; > >>>> namely, it no longer protects against classes of attacks > >> that do not=20 > >>>> intend to establish sessions as such (this discussion would come > >>>> around to things like early media and forking, for > >> example; there are > >>>> also applicability concerns here with media protocols other than > >>>> RTP). If these were the only two possible solutions, they > >> we'd debate=20 > >>>> their merits and flaws, pick one, and be done. I at least haven't > >>>> given up on the idea that we can draw up some other candidate > >>>> solutions; the real bar to doing so seems to me to be=20 > disagreement > >>>> about the problem space. > >>>> So for the moment, I am still trying to talk at a pretty > >> high level=20 > >>>> about what sorts of qualities are desirable in a solution. > >>>>=20 > >>>> Jon Peterson > >>>> NeuStar, Inc. > >>>>=20 > >>>>> John > >>>>=20 > >>>>=20 > >>=20 > >>=20 >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From apike3@csc.com Mon Apr 13 10:52:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1C13A6D1F for ; Mon, 13 Apr 2009 10:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_55=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSKs8GSOtkxH for ; Mon, 13 Apr 2009 10:52:11 -0700 (PDT) Received: from mail130.messagelabs.com (mail130.messagelabs.com [216.82.250.163]) by core3.amsl.com (Postfix) with ESMTP id 6F17D3A6E91 for ; Mon, 13 Apr 2009 10:51:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: apike3@csc.com X-Msg-Ref: server-6.tower-130.messagelabs.com!1239645159!20372935!3 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 10746 invoked from network); 13 Apr 2009 17:52:41 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-6.tower-130.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Apr 2009 17:52:41 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n3DHqdg4025151; Mon, 13 Apr 2009 13:52:41 -0400 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <009d01c9bc5e$b5395170$c5f0200a@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF1D5F2B8B@zrc2hxm0.corp.nortel.com> , <009d01c9bc5e$b5395170$c5f0200a@cisco.com> MIME-Version: 1.0 From: Anthony D Pike To: "Dan Wing" Message-ID: Date: Mon, 13 Apr 2009 13:52:38 -0400 X-Mailer: Lotus Domino Web Server Release 8.0.1 February 07, 2008 X-MIMETrack: Serialize by Notes Server on AMER-ML20/SRV/CSC(Release 8.0.1|February 07, 2008) at 04/13/2009 13:52:38, Serialize complete at 04/13/2009 13:52:38, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 04/13/2009 01:54:46 PM MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 'Cullen Jennings' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 17:52:13 -0000 +1

This is a PRIVATE message. I= f you are not the intended recipient, please delete without copying and kin= dly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of= content, this e-mail shall not operate to bind CSC to any order or other c= ontract unless pursuant to explicit written agreement or government initiat= ive expressly permitting the use of e-mail for such purpose. =E2=80=A2 

-----sip-bounces@ietf.org wrote: -----

To: "'Jon Peterson'" <jon.= peterson@neustar.biz>, "'Francois Audet'" <audet@nortel.com>, "'El= well, John'" <john.elwell@siemens-enterprise.com>, "'Dean Willis'" &l= t;dean.willis@softarmor.com>
From: "Dan Wing" <dwing@cisco.com>=
Sent by: sip-bounces@ietf.org
Date: 04/13/2009 01:38PM
cc: "'Cull= en Jennings'" <fluffy@cisco.com>, sip@ietf.org, "'DRAGE, Keith \(Keit= h\)'" <drage@alcatel-lucent.com>
Subject: Re: [Sip] francois' comm= ents and why RFC4474 not used in the field



> -----Original M= essage-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
> B= ehalf Of Jon Peterson
> Sent: Friday, April 10, 2009 12:28 PM
>= To: Francois Audet; Elwell, John; Dean Willis
> Cc: Cullen Jennings;= sip@ietf.org; DRAGE,Keith (Keith)
> Subject: Re: [Sip] francois' com= ments and why RFC4474 not
> used in the field
>
> If I = may quibble here:
>
> > The attack is not impersonation, it= 's interruption of media.
>
> The attack relies on impersonati= on to accomplish interruption
> of media. The
> attacker liste= ns to Alice's INVITE, and then sends a cut-and-pasted
> re-INVITE say= ing "This is Alice again, would you mind sending
> my media here
= > instead please."

The 'Alice again' attacker would need to prove= Alice's identity which
the attacker cannot accomplish (unless the atta= cker knows Alice's
private key).  This is true of RFC4474 and
= draft-fischer-sip-e2e-sec-media and draft-wing-sip-identity-media.
All t= hree of those require the attacker to sign SIP headers and,
in the case = of the two I-D's, the attacker has to also perform
a handshake proving p= ossession of Alice's private key.

I don't see the new attack that yo= u are seeing.

-d

> Impersonation is almost always a tool t= hat
> attackers use to
> accomplish some particular goal, even= if it's just tricking you into
> accepting unwanted communications. = I'm not sure I'd say
> impersonation is an
> attack as such, b= ut by preventing it, we prevent whole
> categories of attacks
>= ; and grant ourselves more powers in crafting authorization policies.
&g= t;
> Jon Peterson
> NeuStar, Inc.
>
> On 4/10/09 = 11:37 AM, "Francois Audet" <audet@nortel.com> wrote:
>
>= > Yes, this makes sense to me.
> >
> > The attack is= not impersonnation, it's interuption of media.
> >
> > = Verifying the address of the relay seems difficult to me. It could
> = > be in source domain, destination domain, some intermediary. Or there> > could even be more than one. Unless we do it hop by hop.
>= ; >
> > I guess we could have another layer of TLS exchange be= tween the
> > UA and the intermediary (where instead of a self-sig= ned cert,
> > you would actually autenticate your intermediary). W= ouldn't do
> > wonders for backward compatibility however, and I'm= not sure
> > it would be simpler than TURN.
> >
>= >> -----Original Message-----
> >> From: Jon Peterson [<= A href=3D"mailto:jon.peterson@neustar.biz" target=3Dblank >mailto:jon.peter= son@neustar.biz]
> >> Sent: Friday, April 10, 2009 09:10> >> To: Audet, Francois (SC100:3055); Elwell, John; Dean Willis<= BR>> >> Cc: Cullen Jennings; sip@ietf.org; DRAGE,Keith (Keith)
= > >> Subject: Re: [Sip] francois' comments and why RFC4474 not
= > >> used in the field
> >>
> >>
>= >> At a high level, when an intermediary is going to relay your
&= gt; >> media, the intermediary (not the UAC) is the source of the
= > >> IP/port data that appears in SDP, and as such, I can accept> >> alternatives to securing that data with a signature from th= e
> >> originating administrative domain (abstractly, that goes=
> >> equally for SBCs and TURN, I suppose). I don't however> >> believe it follows from this that it just doesn't matter at<= BR>> >> all who sets the IP/port data in SDP. I think it does matt= er,
> >> and it matters most when we consider approaches that d= efer
> >> security checks from the SIP layer to the media layer= . For
> >> example, if relatively weak SIP-layer security facil= itates
> >> cut-and-paste attacks, then an eavesdropper could l= isten to
> >> INVITEs, forge re-INVITEs with the same signature= but set the
> >> IP/port to something unhelpful, and methodica= lly tear down a
> >> target's calls five seconds after they sta= rt. So from my
> >> perspective, verifying the origin of IP/por= t data still has
> >> value, even if the origin of that data is= not the originating
> >> administrative domain.
> >&g= t;
> >> Jon Peterson
> >> NeuStar, Inc.
> &g= t;>
> >>
> >> On 4/9/09 12:09 PM, "Francois Au= det" <audet@nortel.com> wrote:
> >>
> >>>= So, at a high level, if we could "sign the blob" =C3=A0-la-RFC
> 44= 74, but
> >>> exclude very specific elements (i.e., the IP:p= ort), and combine it
> >>> with DTLS-SRTP (or TLS for non-re= al time media), in specific cases
> >>> where allowing Media= Relays is desireable/necessary, then
> >> we may have
>= >>> a solution, right?
> >>>
> >>>= I'm interpreting your email as we should have an opt-out of
> >&g= t; integrity
> >>> protection (carefully used) instead of a= n opt-in (as per the
> >>> draft-wing-identity-media draft).=
> >>>
> >>>
> >>>
> = >>>> -----Original Message-----
> >>>> From: = Jon Peterson [m= ailto:jon.peterson@neustar.biz]
> >>>> Sent: Thursday= , April 09, 2009 11:50
> >>>> To: Elwell, John; Audet, Fr= ancois (SC100:3055); Dean Willis
> >>>> Cc: Cullen Jennin= gs; sip@ietf.org; DRAGE,Keith (Keith)
> >>>> Subject: Re:= [Sip] francois' comments and why RFC4474 not
> >> used in the =
> >>>> field
> >>>>
> >>&= gt;>
> >>>>> [JRE] If media is encrypted, sending = it to the wrong IP
> >>>> address/port,
> >>&= gt;>> whilst it will cause the call to fail, will not reveal the
&= gt; >>>> information
> >>>>> to the recipi= ent. Of course, if media is not encrypted,
> >>>> that ha= s worse
> >>>>> consequences, but unencrypted media ca= n be eavesdropped by other
> >>>>> mechanisms, or can = be spoofed or modified. Knowing who told
> >>>> you which=
> >>>>> IP address/port to send to only gives you a c= ertain amount
> >>>> of protection.
> >>>&= gt;> We must ensure we do not lower the security available when
> = >>>> encryption
> >>>>> is in use (losing = the ability to authenticate the user we
> >> performed
>= >>>>> key agreement with) by clinging on to mechanisms that= give
> >>>> some minor
> >>>>> bene= fit to the unencrypted case.
> >>>>
> >>>= > In fairness, I don't think the choice is between signing
> >&= gt; the IP/port
> >>>> and not signing the IP/port. It i= s between signing the
> entire MIME
> >>>> body as= a blob the auth service does not have to
> >> understand, vers= us
> >>>> selecting a set of elements (understood here no= t to include the
> >>>> IP/port) and signing those exclus= ively. If we want to
> >> understand the
> >>>&= gt; benefits of the former approach, they go a bit beyond
> >> = protecting the
> >>>> IP/port.
> >>>> = Architecturally, signing the blob results in better future
> >>= >> compatibility and better paths to extending SDP. If the
> &g= t;>>> authentication service needs to know what elements in SDP> >> are to be
> >>>> included in the signatur= e, then the authentication service
> >> behavior
> >&= gt;>> needs to change every time that clients start using SDP
>= >> (or bodies,
> >>>> for that
> >>&g= t;> matter) in new ways.
> >>>>
> >>>&= gt; If someone wakes up tomorrow, invents a new media security
> >= > model, and
> >>>> decides there is value in having = an indicator in SDP
> that will let
> >>>> you cor= relate the rendezvous layer with media security
> >> keying, un= der
> >>>> the blob model that indicator can just get st= uck in SDP, and the
> >>>> authentication service does no= t need to change its
> >> behavior in order
> >>>= ;> to sign it.
> >>>> Taking this to its extreme, whil= e I'm sure no one would
> >> stand up to
> >>>&= gt; defend SDPng these days, virtually everyone would say that
> >= > SDP isn't
> >>>> the ideal tool for establishing co= mplicated sessions; if
> >> we ever do
> >>>>= ; get around to building something better, the
> >> authenticat= ion service
> >>>> in the blob signature model shouldn't = need to understand
> >> it. This is,
> >>>> = again, just a basic SIP layering architecture we've always
> >>= followed,
> >>>> intended to maximize the ability of en= dpoints to innovate
> >> and reduce
> >>>> t= he brittleness of intermediaries.
> >>>>
> >>= ;>> Even without looking to the future, I think there's
> >&= gt; reasonable value
> >>>> in signing most of the cruft = in SDP. For example, as I've
> >> mentioned
> >>&g= t;> before, I think it's worth detecting various codec
> >> = downgrade sorts of
> >>>> attacks. But speaking to the IP= /port again specifically, I
> >> maintain
> >>>= > that when sending media doesn't work, it is useful for UAS to
> = >>>> ascertain who set the target IP/port, and if the IP/port> >> shouldn't be
> >>>> tried anyway because= they were inserted by an attacker, I
> >> think it's
> = >>>> useful for the UAS to know that before it processes that> >> re-INVITE,
> >>>> or begins altering for= that initial INVITE, or what have you.
> >>>>
> &= gt;>>>>> broadly I
> >>>>>> think it= doesn't address threats where an
> >>>> attacker/imperso= nator can
> >>>>>> accomplish their goals without e= ver establishing a
> >> session. If we
> >>>>= ;>> think about, I suspect we'll find there are actually quite
>= ; >>>> a few of those.
> >>>>> [JRE] So th= is suggests the need for two solutions: one for
> >>>> pr= otecting
> >>>>> the rendez-vous layer and one for pro= tecting the media
> layer. The
> >>>>> problem = is that the mechanism for protecting the
> >> rendez-vous layer=
> >>>>> (RFC
> >>>>> 4474) does = not work in certain deployment situations, and
> >>>> bec= ause we
> >>>>> reuse that for authenticating the medi= a layer (using it
> >> to sign the
> >>>>>= ; fingerprint of the certificate used at the media layer) we
> >&g= t;>> are unable
> >>>>> to have protection of th= e media layer in those deployment
> >>>> situations.
&= gt; >>>>
> >>>> Certainly I agree that RFC44= 74 interprets "certain deployment
> >>>> situations" as s= ecurity violations, and that is a
> >> limitation of its
>= ; >>>> approach. I was merely pointing out that there are also<= BR>> >> limitations
> >>>> to an approach where= we largely defer security to the
> media layer;
> >>>= ;> namely, it no longer protects against classes of attacks
> >= > that do not
> >>>> intend to establish sessions as = such (this discussion would come
> >>>> around to things = like early media and forking, for
> >> example; there are
&g= t; >>>> also applicability concerns here with media protocols o= ther than
> >>>> RTP). If these were the only two possibl= e solutions, they
> >> we'd debate
> >>>> th= eir merits and flaws, pick one, and be done. I at least haven't
> >= ;>>> given up on the idea that we can draw up some other candidate=
> >>>> solutions; the real bar to doing so seems to me t= o be
> disagreement
> >>>> about the problem space= .
> >>>> So for the moment, I am still trying to talk at = a pretty
> >> high level
> >>>> about what s= orts of qualities are desirable in a solution.
> >>>> > >>>> Jon Peterson
> >>>> NeuStar, Inc.<= BR>> >>>>
> >>>>> John
> >>= ;>>
> >>>>
> >>
> >> >
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip<= /A>
> This list is for NEW development of the core SIP Protocol
&g= t; Use sip-implementors@cs.columbia.edu for questions on current sip
>= ; Use sipping@ietf.org for new developments on the application of sip
&g= t;

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
T= his list is for NEW development of the core SIP Protocol
Use sip-impleme= ntors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org = for new developments on the application of sip

<= /FONT>= From jon.peterson@neustar.biz Mon Apr 13 11:19:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3470A3A6DCF for ; Mon, 13 Apr 2009 11:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 u4kNiI0qGLZc for ; Mon, 13 Apr 2009 11:19:15 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 2A0723A6DCA for ; Mon, 13 Apr 2009 11:19:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1239646824; x=1239733224; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=a+8iqn4MndaQRKKe4jvUlyX0pMahQt9yffC14Czr9oSg1iGER/teUUJwlxCBgMXxZblrF3CmBLVPeo cMPzMdGg== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.17442313; Mon, 13 Apr 2009 14:20:05 -0400 Received: from 10.31.13.114 ([10.31.13.114]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Apr 2009 18:20:04 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 13 Apr 2009 11:20:04 -0700 From: Jon Peterson To: Dan Wing , 'Francois Audet' , "'Elwell, John'" , Dean Willis Message-ID: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sABO07UAACAyOlAJLdPdAAAaBeFg== In-Reply-To: <009d01c9bc5e$b5395170$c5f0200a@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 18:19:16 -0000 I don't think I'm describing any novel attack here, and really I am trying to speak more to higher-level requirements than the properties of any specific proposal, but I'd like to understand what our disconnect is. I'm talking about an attack that is purely in the signaling layer, so I'm not sure in what sense Alice has a private key applicable to that layer (unless she is acting as her own authentication service, say). "This is Alice again" here means that, for example, the re-INVITE is a clever cut-and-paste attack that appears to have a valid signature to verifier. The decision about where media is sent is always something negotiated in the rendezvous layer; if the rendezvous layer is persuaded to send media somewhere unhelpful, no amount of media layer security will prevent this disruption. The only thing this attack is meant to illustrate is why it does matter who sets the IP/port. I've gathered that some people in the discussion reject the notion that there are any threats related to the setting the IP/port in the signaling layer, so I'm trying to provide an example. Jon Peterson NeuStar, Inc. On 4/13/09 10:38 AM, "Dan Wing" wrote: > The 'Alice again' attacker would need to prove Alice's identity which > the attacker cannot accomplish (unless the attacker knows Alice's > private key). This is true of RFC4474 and > draft-fischer-sip-e2e-sec-media and draft-wing-sip-identity-media. > All three of those require the attacker to sign SIP headers and, > in the case of the two I-D's, the attacker has to also perform > a handshake proving possession of Alice's private key. > > I don't see the new attack that you are seeing. > > -d From dwing@cisco.com Mon Apr 13 11:36:52 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E10F3A6AF7 for ; Mon, 13 Apr 2009 11:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+J5ncob9AWm for ; Mon, 13 Apr 2009 11:36:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 122D03A67DF for ; Mon, 13 Apr 2009 11:36:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,180,1238976000"; d="scan'208";a="170870141" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 Apr 2009 18:38:02 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3DIc2Ui024801; Mon, 13 Apr 2009 11:38:02 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3DIc1IH010986; Mon, 13 Apr 2009 18:38:01 GMT From: "Dan Wing" To: "'Jon Peterson'" , "'Francois Audet'" , "'Elwell, John'" , "'Dean Willis'" References: <009d01c9bc5e$b5395170$c5f0200a@cisco.com> Date: Mon, 13 Apr 2009 11:38:01 -0700 Message-ID: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> 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: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sABO07UAACAyOlAJLdPdAAAaBeFgAAfZ3w DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2524; t=1239647882; x=1240511882; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=PzBkaefQAONWFwu3fLWr6umjBal7UBcomfa3mflnKs4=; b=fDcXe0Rqlx4WTbXQHVvSlEXujoIwuyjjMhjz4TwjcUZeN4ZOtuHyvB1i3q Gjy9OW9HAMnIxZbI1YIRQkP1LJYwx5BihleFSFJXHSoVwHw7IAjFQ0F0pb/4 tN1IKqdTZv; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Cullen Jennings' , sip@ietf.org, "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 18:36:52 -0000 > -----Original Message----- > From: Jon Peterson [mailto:jon.peterson@neustar.biz] > Sent: Monday, April 13, 2009 11:20 AM > To: Dan Wing; 'Francois Audet'; 'Elwell, John'; Dean Willis > Cc: Cullen Jennings; sip@ietf.org; 'DRAGE,Keith (Keith)' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > I don't think I'm describing any novel attack here, and > really I am trying > to speak more to higher-level requirements than the properties of any > specific proposal, but I'd like to understand what our > disconnect is. I believe there is consensus that cut-and-paste attacks need to be prevented. You continue to raise that point, so I can only assume that you believe there is a lack of consensus on that point. > I'm > talking about an attack that is purely in the signaling > layer, so I'm not > sure in what sense Alice has a private key applicable to that > layer (unless > she is acting as her own authentication service, say). "This > is Alice again" > here means that, for example, the re-INVITE is a clever > cut-and-paste attack > that appears to have a valid signature to verifier. The > decision about where > media is sent is always something negotiated in the > rendezvous layer; if the > rendezvous layer is persuaded to send media somewhere > unhelpful, no amount > of media layer security will prevent this disruption. > > The only thing this attack is meant to illustrate is why it > does matter who > sets the IP/port. I've gathered that some people in the > discussion reject > the notion that there are any threats related to the setting > the IP/port in > the signaling layer, so I'm trying to provide an example. That is because, ** in conjunction with media-path validation ** (which is the important point), the attack is prevented. -d > Jon Peterson > NeuStar, Inc. > > > On 4/13/09 10:38 AM, "Dan Wing" wrote: > > > The 'Alice again' attacker would need to prove Alice's > identity which > > the attacker cannot accomplish (unless the attacker knows Alice's > > private key). This is true of RFC4474 and > > draft-fischer-sip-e2e-sec-media and draft-wing-sip-identity-media. > > All three of those require the attacker to sign SIP headers and, > > in the case of the two I-D's, the attacker has to also perform > > a handshake proving possession of Alice's private key. > > > > I don't see the new attack that you are seeing. > > > > -d > From dean.willis@softarmor.com Mon Apr 13 12:19:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640163A6D90 for ; Mon, 13 Apr 2009 12:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 sh3TzmYpImzx for ; Mon, 13 Apr 2009 12:19:40 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7756C3A6D8E for ; Mon, 13 Apr 2009 12:19:40 -0700 (PDT) Received: from [192.168.2.101] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3DJKLE3004696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Apr 2009 14:20:22 -0500 Message-Id: From: Dean Willis To: "Dan Wing" In-Reply-To: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 14:20:15 -0500 References: <009d01c9bc5e$b5395170$c5f0200a@cisco.com> <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: 'Cullen Jennings' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 19:19:41 -0000 On Apr 13, 2009, at 1:38 PM, Dan Wing wrote: > > That is because, ** in conjunction with media-path validation ** > (which is the important point), the attack is prevented. Well, the attack is not so much "prevented" as it is "detected". It is detectable when the media-path validation fails. But though detectable, the attack is not attributable. You may know that an attack has occurred, but you don't know whether it was enabled by modification of the media or by modification of the signaling. If you had the original signed signaling and could see that the signaling had been altered, then you might reasonably suspect that the attacker was on the signaling path. Without this, all you know is that somebody tweened your media somehow. Now, is this really useful if the original signed media description (SDP) has been replaced by new signed SDP? Not really; as we then would not be able to decide whether the attack was a compromised intermediary authentication server or a a direct attack on the media. So a model wherein no intermediary replaces and resigns the SDP is preferred, as it allows the media to always match the signaling, thereby reducing the uncertainty. We don't have such a model yet AFAIK, as outbound, STUN, and relays give us only two steering points, and I've heard it claimed we need more. I might argue that this problem is due to the separation of signaling and media, which I hold to be one of the prime "complicators" in this whole house of cards. But it might well be possible to extend the relay-discovery model of ICE to be able to express an entire graph of candidate sequences, including n-relay paths. On the otehr hand, I find it difficult to propose such a mechanism that would be backward compatible with the SIP devices I currently use, and if we have to breal backward compatibility, I'd just as soon do it cleanly and on a large scale. -- Dean From jon.peterson@neustar.biz Mon Apr 13 12:21:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28F33A6939 for ; Mon, 13 Apr 2009 12:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 2Evj5oA1ZHn4 for ; Mon, 13 Apr 2009 12:21:14 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id DECDB3A68F3 for ; Mon, 13 Apr 2009 12:21:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1239650544; x=1239736944; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=qPsBIF9G/MzAvzIMaNbKVff2AakufelTlK01Ikcy27D5X0vp1iXAjlTDbO+ctDK/hvwjxIacFcjKkf IhKC1MuQ== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.17444237; Mon, 13 Apr 2009 15:22:05 -0400 Received: from 10.31.13.114 ([10.31.13.114]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Apr 2009 19:22:04 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 13 Apr 2009 12:22:04 -0700 From: Jon Peterson To: Dan Wing , 'Francois Audet' , "'Elwell, John'" , Dean Willis Message-ID: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sABO07UAACAyOlAJLdPdAAAaBeFgAAfZ3wAAGstvY= In-Reply-To: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 19:21:15 -0000 >> The only thing this attack is meant to illustrate is why it does matter who >> sets the IP/port. I've gathered that some people in the discussion reject >> the notion that there are any threats related to the setting the IP/port in >> the signaling layer, so I'm trying to provide an example. > > That is because, ** in conjunction with media-path validation ** > (which is the important point), the attack is prevented. You're talking about a solution here; I'm really trying to establish that there's a problem. The two are not mutually exclusively - ideally we will have both a problem and a solution. I am however uncertain that we have a common understanding of the problem. I'm not sure I know what you mean by media-path validation, here, but I do think that there are many important attacks against SIP that accomplish their aims without ever establishing a media session. These include signaling-layer attacks that would, for example, tear down the media associated with an existing call. I have a hard time seeing how anything we do at the media layer is salient to that - again, just speaking to high level examples, if you accept a forged BYE request, that will presumably convince you to tear down a call regardless of anything that media-layer security has established. I've argued a similar requirement exists to prevent a forged re-INVITE that just sets the IP/port to something useless. When I hear you say that some property of media path prevents this sort of attack, then I gather we must disagree about the problem, not just the solution. Can you explain a bit what you mean here by media-path validation and how it prevents the sorts of attacks I just mentioned? Jon Peterson NeuStar, Inc. > -d From florz@florz.de Mon Apr 13 13:49:33 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061163A6A86 for ; Mon, 13 Apr 2009 13:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.808 X-Spam-Level: X-Spam-Status: No, score=-0.808 tagged_above=-999 required=5 tests=[AWL=1.180, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOygt5HSLLdM for ; Mon, 13 Apr 2009 13:49:32 -0700 (PDT) Received: from rain.florz.dyndns.org (rain.florz.de [62.216.164.86]) by core3.amsl.com (Postfix) with ESMTP id E406D3A67D8 for ; Mon, 13 Apr 2009 13:49:31 -0700 (PDT) Received: from florz.florz.dyndns.org ([192.168.0.121]) by rain.florz.dyndns.org with esmtp (Exim 4.63) (envelope-from ) id 1LtT6i-0001UL-JK; Mon, 13 Apr 2009 22:50:20 +0200 Received: from florz by florz.florz.dyndns.org with local (Exim 3.35 #1 (Debian)) id 1LtT6h-0006I2-00; Mon, 13 Apr 2009 22:50:19 +0200 Date: Mon, 13 Apr 2009 22:50:19 +0200 From: Florian Zumbiehl To: sip@ietf.org Message-ID: <20090413205019.GI8282@florz.florz.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: fluffy@cisco.com, rohan@ekabal.com Subject: [Sip] bug #1 in draft-ietf-sip-outbound-16 grammar X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 20:49:33 -0000 Hi, in case you've read my bug report concerning draft-ietf-sip-gruu-15 from this morning, the short version: draft-ietf-sip-outbound-16 is affected by the same problem. The complete version: draft-ietf-sip-outbound-16 contains (amongst others) these ABNF rules: | contact-params =/ c-p-reg / c-p-instance | c-p-instance = "+sip.instance" EQUAL | LDQUOT "<" instance-val ">" RDQUOT which, when adding them to the grammar from RFC 3261, would produce from a language that's a superset of the language that would be produced by from RFC 3261-only. In particular, the language produced by is a subset of the "outbound extended" language, but not of the RFC 3261-only one: | foo = "m: ;+sip.instance=" DQUOTE "x" DQUOTE SP CRLF To put it in more practical terms: the in allows for trailing , which does not, so an implementation conforming to draft-ietf-sip-outbound-16 could produce a Contact header that potentially could not be parsable (except as an ) by an implementation conforming to RFC 3261. Thus, I would suggest to replace the rules quoted above by: | contact-params =/ c-p-reg / c-p-instance | c-p-instance = "+sip.instance" EQUAL | LDQUOT "<" instance-val ">" DQUOTE This produces the same language, maybe it's a more consistent replacement: | contact-params =/ c-p-reg / c-p-instance | c-p-instance = "+sip.instance" EQUAL | DQUOTE "<" instance-val ">" DQUOTE Florian From dworley@nortel.com Mon Apr 13 14:05:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE883A6A36 for ; Mon, 13 Apr 2009 14:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPhNlTd96aYq for ; Mon, 13 Apr 2009 14:05:10 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 59C563A67A4 for ; Mon, 13 Apr 2009 14:05:10 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3DL5OQ18520; Mon, 13 Apr 2009 21:05:24 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 17:06:03 -0400 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <49E35108.4080506@cisco.com> References: <20090413025431.GB7795@florz.florz.dyndns.org> <61968779B8AC4C4BAB421D4C12F008C01C74814A@XCH47YKF.rim.net> <49E35108.4080506@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 13 Apr 2009 17:06:02 -0400 Message-Id: <1239656762.5635.6.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2009 21:06:03.0111 (UTC) FILETIME=[A7549F70:01C9BC7B] Cc: sip@ietf.org Subject: Re: [Sip] bug in draft-ietf-sip-gruu-15 grammar X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 21:05:11 -0000 On Mon, 2009-04-13 at 10:49 -0400, Paul Kyzivat wrote: > Its been quite awhile and my memory may be getting a little fuzzy on > this, but... > > As I recall there are some very subtle points about this. There are > cases where someone other than the UA doing the registering may need the > gruu. So the UA that registers its contact may not support GRUU, the > gruu need be allocated so others can use it. For instance, if some other > UA registers the same AOR, and does support gruu, it will get back all > the contacts, and should get back gruus for all of them. Similarly, any > who subscribe to the reg event package. You're correct. It was explicitly designed that the registrar would create a GRUU even if the UA registering did not support GRUU. In particular, this GRUU would be visible in reg events for the AoR in question, which allows *other* UAs that want to know the GRUU of the registering UA to find it. (E.g., the sipX open-source PBX takes advantage of this.) Dale From rohan@ekabal.com Mon Apr 13 14:08:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1953A69F1 for ; Mon, 13 Apr 2009 14:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Hgq0O1UwnRx6 for ; Mon, 13 Apr 2009 14:08:21 -0700 (PDT) Received: from postalmail-a5.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id 889423A6EAE for ; Mon, 13 Apr 2009 14:08:21 -0700 (PDT) Received: from [192.168.1.200] (c-67-160-240-12.hsd1.ca.comcast.net [67.160.240.12]) by postalmail-a5.g.dreamhost.com (Postfix) with ESMTP id 426EEBE99D; Mon, 13 Apr 2009 14:09:32 -0700 (PDT) Message-Id: From: Rohan Mahy To: Florian Zumbiehl In-Reply-To: <20090413205019.GI8282@florz.florz.dyndns.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 14:09:30 -0700 References: <20090413205019.GI8282@florz.florz.dyndns.org> X-Mailer: Apple Mail (2.930.3) Cc: sip@ietf.org, Rohan Mahy , fluffy@cisco.com Subject: Re: [Sip] bug #1 in draft-ietf-sip-outbound-16 grammar X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 21:08:22 -0000 Hi Florian, I think the intent of RFC3261 should have been to allow optional whitespace at the end of a quoted-string: Currently in RFC 3261: quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE Probably should have been in RFC 3261: quoted-string = LDQUOT *(qdtext / quoted-pair ) RDQUOT However, that is water under the bridge, so I have no objection changing the c-p-instance production to look like this: c-p-instance = "+sip.instance" EQUAL DQUOTE "<" instance-val ">" DQUOTE If you are responsible for an implementation however, I urge you to be generous in what you receive in this regard. Please ignore extraneous whitespace unless the spec gives it some special semantic meaning (ex: inside a quoted string). thanks, -rohan On Apr 13, 2009, at 1:50 PM, Florian Zumbiehl wrote: > Hi, > > in case you've read my bug report concerning draft-ietf-sip-gruu-15 > from this morning, the short version: draft-ietf-sip-outbound-16 is > affected by the same problem. > > The complete version: > > draft-ietf-sip-outbound-16 contains (amongst others) these ABNF rules: > > | contact-params =/ c-p-reg / c-p-instance > | c-p-instance = "+sip.instance" EQUAL > | LDQUOT "<" instance-val ">" RDQUOT > > which, when adding them to the grammar from RFC 3261, would produce > from a language that's a superset of the language that would > be produced by from RFC 3261-only. > > In particular, the language produced by is a subset of the > "outbound extended" language, but not of the RFC 3261-only one: > > | foo = "m: ;+sip.instance=" DQUOTE "x" DQUOTE SP CRLF > > To put it in more practical terms: the in > allows for trailing , which does not, > so an implementation conforming to draft-ietf-sip-outbound-16 could > produce a Contact header that potentially could not be parsable > (except as an ) by an implementation conforming > to RFC 3261. > > Thus, I would suggest to replace the rules quoted above by: > > | contact-params =/ c-p-reg / c-p-instance > | c-p-instance = "+sip.instance" EQUAL > | LDQUOT "<" instance-val ">" DQUOTE > > This produces the same language, maybe it's a more consistent > replacement: > > | contact-params =/ c-p-reg / c-p-instance > | c-p-instance = "+sip.instance" EQUAL > | DQUOTE "<" instance-val ">" DQUOTE > > Florian From dworley@nortel.com Mon Apr 13 14:15:17 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DEF53A6924 for ; Mon, 13 Apr 2009 14:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txBwzLF6XuBB for ; Mon, 13 Apr 2009 14:15:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6CF6A3A68A1 for ; Mon, 13 Apr 2009 14:15:13 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3DLFqM13138; Mon, 13 Apr 2009 21:15:52 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 17:15:51 -0400 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <49CA355F.4040100@cisco.com> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> <1237940172.443.35.camel@victoria-pingtel-com.us.nortel.com> <49CA355F.4040100@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 13 Apr 2009 17:15:50 -0400 Message-Id: <1239657350.5635.8.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2009 21:15:51.0576 (UTC) FILETIME=[06154180:01C9BC7D] Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 21:15:17 -0000 On Wed, 2009-03-25 at 09:45 -0400, Paul Kyzivat wrote: > That is why dialog matching should still be done. I have no business > inventing a To-tag for you. It has to be *your* To-tag. If you don't > recognize it then you send me a 481. Ah, yes, I'd overlooked that out-of-dialog and in-dialog requests are syntactically distinguishable, rather than being distinguished by whether the recipient has previously seen a request with the same call-id. Dale From florz@florz.de Mon Apr 13 14:16:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61FC3A68A1 for ; Mon, 13 Apr 2009 14:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=0.984, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yg+KCqkwvIG for ; Mon, 13 Apr 2009 14:16:12 -0700 (PDT) Received: from rain.florz.dyndns.org (rain.florz.de [62.216.164.86]) by core3.amsl.com (Postfix) with ESMTP id 0BE4D3A6E2F for ; Mon, 13 Apr 2009 14:15:56 -0700 (PDT) Received: from florz.florz.dyndns.org ([192.168.0.121]) by rain.florz.dyndns.org with esmtp (Exim 4.63) (envelope-from ) id 1LtTWR-00023N-U1; Mon, 13 Apr 2009 23:16:56 +0200 Received: from florz by florz.florz.dyndns.org with local (Exim 3.35 #1 (Debian)) id 1LtTWR-0006R4-00; Mon, 13 Apr 2009 23:16:55 +0200 Date: Mon, 13 Apr 2009 23:16:55 +0200 From: Florian Zumbiehl To: sip@ietf.org Message-ID: <20090413211654.GJ8282@florz.florz.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: fluffy@cisco.com, rohan@ekabal.com Subject: [Sip] bug #2 in draft-ietf-sip-outbound-16 grammar X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 21:16:12 -0000 Hi, draft-ietf-sip-outbound-16 contains (amongst others) these ABNF rules: | message-header =/ Flow-Timer | Flow-Timer = "Flow-Timer" HCOLON 1*DIGIT which, when adding them to the grammar from RFC 3261, would produce from a language that's a superset of the language that would be produced by from RFC 3261-only. In particular, the language produced by is a subset of the "outbound extended" language, but not of the RFC 3261-only one: | foo = "INVITE sip:x@10.0.0.1 SIP/2.0" CRLF "Flow-Timer: 1" CRLF %x00 ":" LF Well, seriously: in RFC 3261 contains the final CRLF that marks the end of a header, the newly-added alternative does not, I guess that it's rather obvious that that is broken. So, I would suggest replacing the rules quoted above by the following: | message-header =/ Flow-Timer CRLF | Flow-Timer = "Flow-Timer" HCOLON 1*DIGIT Florian From dworley@nortel.com Mon Apr 13 14:18:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678C23A6EC7 for ; Mon, 13 Apr 2009 14:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6a9S1pjGsLu for ; Mon, 13 Apr 2009 14:18:37 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 631283A6ECB for ; Mon, 13 Apr 2009 14:18:37 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3DLJ1Q20087; Mon, 13 Apr 2009 21:19:01 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 17:19:40 -0400 From: "Dale Worley" To: Hans Erik van Elburg In-Reply-To: <9ae56b1e0903270533tf8cbb4dh44fe66ef605be34c@mail.gmail.com> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> <49C8F18D.1040800@cisco.com> <49CCC1A1.9040501@cisco.com> <9ae56b1e0903270533tf8cbb4dh44fe66ef605be34c@mail.gmail.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 13 Apr 2009 17:19:39 -0400 Message-Id: <1239657579.5635.12.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2009 21:19:40.0471 (UTC) FILETIME=[8E83DC70:01C9BC7D] Cc: SIP IETF , Paul Kyzivat , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 21:18:38 -0000 On Fri, 2009-03-27 at 13:33 +0100, Hans Erik van Elburg wrote: > 3rd party contact center desktop monitoring > application is used by the supervisor to see agent's > activities. Thru a CTI <->SIP translator, it SUBs to > the agent's presence. Once the customer service agent > comes in the morning and turns his phone's status to > Online(Open), app notices this and forces it to > Register. At the end of the day when agent leaves, > does the opposite and de-registers it. Thus, it is > made sure that they only get billed for the time that > agent was registered(online) by the service provider. > That, AND why would you not use the OPEN line button to just REGISTER? > And make the application be notified that the > registration/deregistration happened. E.g., the monitoring application can subscribe to 'reg' events for the agent's AOR. When the agent activates his phone, the phone registers. The monitoring application is notified of the registration, which simultaneously tells the monitoring application of the contact URI (and/or GRUU) of the agent's phone. This lets the monitoring application perform 3pcc operations. Dale From dean.willis@softarmor.com Mon Apr 13 15:24:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1513A6DC7 for ; Mon, 13 Apr 2009 15:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 hQFRXxWJ4Xr3 for ; Mon, 13 Apr 2009 15:24:12 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A18E328C14F for ; Mon, 13 Apr 2009 15:24:12 -0700 (PDT) Received: from [192.168.2.101] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3DMPDLb006040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Apr 2009 17:25:15 -0500 Message-Id: <805C9102-5B10-4EA2-B0AC-A53C2EDA8045@softarmor.com> From: Dean Willis To: Rohan Mahy In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 17:25:07 -0500 References: <20090413205019.GI8282@florz.florz.dyndns.org> X-Mailer: Apple Mail (2.930.3) Cc: sip@ietf.org, fluffy@cisco.com Subject: Re: [Sip] bug #1 in draft-ietf-sip-outbound-16 grammar X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 22:24:13 -0000 On Apr 13, 2009, at 4:09 PM, Rohan Mahy wrote: > Hi Florian, > > I think the intent of RFC3261 should have been to allow optional > whitespace at the end of a quoted-string: > > Currently in RFC 3261: > quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE > > Probably should have been in RFC 3261: > quoted-string = LDQUOT *(qdtext / quoted-pair ) RDQUOT > > However, that is water under the bridge, so I have no objection > changing the c-p-instance production to look like this: > > c-p-instance = "+sip.instance" EQUAL DQUOTE "<" instance-val ">" > DQUOTE > > If you are responsible for an implementation however, I urge you to > be generous in what you receive in this regard. Please ignore > extraneous whitespace unless the spec gives it some special semantic > meaning (ex: inside a quoted string). > Is this something we should put in the RFC 3261 errata and essential- corrections process? -- Dean From dwing@cisco.com Mon Apr 13 15:44:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F68028C18A for ; Mon, 13 Apr 2009 15:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPivLOaMdtYi for ; Mon, 13 Apr 2009 15:44:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6C29D28C17B for ; Mon, 13 Apr 2009 15:44:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,181,1238976000"; d="scan'208";a="170989913" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 13 Apr 2009 22:45:20 +0000 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 n3DMjKLj010750; Mon, 13 Apr 2009 15:45:20 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3DMjK3v009736; Mon, 13 Apr 2009 22:45:20 GMT From: "Dan Wing" To: "'Jon Peterson'" , "'Francois Audet'" , "'Elwell, John'" , "'Dean Willis'" References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> Date: Mon, 13 Apr 2009 15:45:20 -0700 Message-ID: <021601c9bc89$865e7ad0$c5f0200a@cisco.com> 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: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sABO07UAACAyOlAJLdPdAAAaBeFgAAfZ3wAAGstvYABvrh8A== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2729; t=1239662720; x=1240526720; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=gC/Jh0d3WG6TOTFxo/r2sV3COgeYPK6SZ8dGmTQC4bQ=; b=Vb/l9CWhIi4uv9ZAx0YYY8rjIfnfN8o1bv6bnjNOCD2YEQTrjd+IE09Z5j yWYmHga6uc1FOg7K2lD4GEMoPBMMk4stta0FoMM/+Mkoqqvg3rvYfZGInmOY 4zSJE7zDqN; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Cullen Jennings' , sip@ietf.org, "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 22:44:10 -0000 > -----Original Message----- > From: Jon Peterson [mailto:jon.peterson@neustar.biz] > Sent: Monday, April 13, 2009 12:22 PM > To: Dan Wing; 'Francois Audet'; 'Elwell, John'; Dean Willis > Cc: Cullen Jennings; sip@ietf.org; 'DRAGE,Keith (Keith)' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > > >> The only thing this attack is meant to illustrate is why > it does matter who > >> sets the IP/port. I've gathered that some people in the > discussion reject > >> the notion that there are any threats related to the > setting the IP/port in > >> the signaling layer, so I'm trying to provide an example. > > > > That is because, ** in conjunction with media-path validation ** > > (which is the important point), the attack is prevented. > > You're talking about a solution here; I'm really trying to > establish that > there's a problem. The two are not mutually exclusively - > ideally we will > have both a problem and a solution. I am however uncertain > that we have a > common understanding of the problem. > > I'm not sure I know what you mean by media-path validation, > here, but I do > think that there are many important attacks against SIP that > accomplish > their aims without ever establishing a media session. These include > signaling-layer attacks that would, for example, tear down the media > associated with an existing call. I have a hard time seeing > how anything we > do at the media layer is salient to that - again, just > speaking to high > level examples, if you accept a forged BYE request, The BYE would be protected from forgery sufficient to detect a forgery, using mechanisms like RFC4474 protects a BYE from forgery: signing enough SIP headers to block a forgery. > that will > presumably > convince you to tear down a call regardless of anything that > media-layer > security has established. I've argued a similar requirement exists to > prevent a forged re-INVITE that just sets the IP/port to > something useless. > When I hear you say that some property of media path prevents > this sort of > attack, then I gather we must disagree about the problem, not just the > solution. Can you explain a bit what you mean here by > media-path validation > and how it prevents the sorts of attacks I just mentioned? The media-path validation is useful for INVITEs which establish media. Other methods, which do not establish media -- BYE, MESSAGE, etc. -- would receive signatures very similar to what RFC4474 does. Namely, some certain SIP headers are signed and, if present, the body is signed. -d > Jon Peterson > NeuStar, Inc. > > > -d > From dwing@cisco.com Mon Apr 13 15:51:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183163A6B71 for ; Mon, 13 Apr 2009 15:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+5o0H4iBLMv for ; Mon, 13 Apr 2009 15:51:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 44E7D3A6858 for ; Mon, 13 Apr 2009 15:51:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,181,1238976000"; d="scan'208";a="285572599" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 13 Apr 2009 22:53:08 +0000 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 n3DMr8H9023635; Mon, 13 Apr 2009 15:53:08 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3DMr8hB016551; Mon, 13 Apr 2009 22:53:08 GMT From: "Dan Wing" To: "'Dean Willis'" References: <009d01c9bc5e$b5395170$c5f0200a@cisco.com> <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> Date: Mon, 13 Apr 2009 15:53:08 -0700 Message-ID: <021a01c9bc8a$9d3e8a00$c5f0200a@cisco.com> 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: Acm8bPUE9XwacJltRBemhSEa3l/X8wAHT61A DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2796; t=1239663188; x=1240527188; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=9zvo3mGwTwTGa1OWQlGuTlsBfM3cpM9kQeaQzsD05f8=; b=WLn/1TaIQsXYpFKGlN49Ar/OoHZ8YMRgY76y4Zqof67myOq1C7T1HIERE6 27LM+sjH11VmrTdx9oDnSAx9LwJTVZ9KGzu5nvY+oH66w/qv4OmoH5rmqrTW +/GFUIcj6y; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Cullen Jennings' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 22:51:58 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, April 13, 2009 12:20 PM > To: Dan Wing > Cc: 'Jon Peterson'; 'Francois Audet'; 'Elwell, John'; 'Cullen > Jennings'; sip@ietf.org; 'DRAGE, Keith (Keith)' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > On Apr 13, 2009, at 1:38 PM, Dan Wing wrote: > > > > That is because, ** in conjunction with media-path validation ** > > (which is the important point), the attack is prevented. > > Well, the attack is not so much "prevented" as it is "detected". It > is detectable when the media-path validation fails. > > But though detectable, the attack is not attributable. You may know > that an attack has occurred, but you don't know whether it > was enabled > by modification of the media or by modification of the signaling. > > If you had the original signed signaling and could see that the > signaling had been altered, then you might reasonably suspect > that the > attacker was on the signaling path. Without this, all you > know is that > somebody tweened your media somehow. > > Now, is this really useful if the original signed media description > (SDP) has been replaced by new signed SDP? Not really; as we then > would not be able to decide whether the attack was a compromised > intermediary authentication server or a a direct attack on the media. > > So a model wherein no intermediary replaces and resigns the SDP is > preferred, as it allows the media to always match the signaling, > thereby reducing the uncertainty. We don't have such a model yet > AFAIK, as outbound, STUN, and relays give us only two > steering points, > and I've heard it claimed we need more. I might argue that this > problem is due to the separation of signaling and media, > which I hold > to be one of the prime "complicators" in this whole house of cards. > But it might well be possible to extend the relay-discovery model of > ICE to be able to express an entire graph of candidate sequences, > including n-relay paths. On the otehr hand, I find it difficult to > propose such a mechanism that would be backward compatible with the > SIP devices I currently use, and if we have to breal backward > compatibility, I'd just as soon do it cleanly and on a large scale. I would be content with identity that worked edge-to-edge, so that existing devices don't need to change. Over time those devices can be upgraded and could do their own proof of identity. The philosophy of RFC4474 was similar in that it allows a-device-other-than-the-UA to create the RFC4474 signature and a-device-other-than-the-UA to validate the RFC4474 signagure. -d From pkyzivat@cisco.com Mon Apr 13 16:26:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420B53A6B17 for ; Mon, 13 Apr 2009 16:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOOwu5wMOzTb for ; Mon, 13 Apr 2009 16:26:29 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 18B2A3A6A13 for ; Mon, 13 Apr 2009 16:26:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,182,1238976000"; d="scan'208";a="41813516" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2009 23:27:39 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3DNRaO6008569; Mon, 13 Apr 2009 19:27:36 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3DNRaGQ007081; Mon, 13 Apr 2009 23:27:36 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Apr 2009 19:27:36 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Apr 2009 19:27:36 -0400 Message-ID: <49E3CA64.1090001@cisco.com> Date: Mon, 13 Apr 2009 19:27:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dale Worley References: <20090413025431.GB7795@florz.florz.dyndns.org> <61968779B8AC4C4BAB421D4C12F008C01C74814A@XCH47YKF.rim.net> <49E35108.4080506@cisco.com> <1239656762.5635.6.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1239656762.5635.6.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2009 23:27:36.0027 (UTC) FILETIME=[6D80C2B0:01C9BC8F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1246; t=1239665256; x=1240529256; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20bug=20in=20draft-ietf-sip-gruu- 15=20grammar |Sender:=20 |To:=20Dale=20Worley=20; bh=EfnBSvDp8PBnS4gi82s4r48HAD4NBSRHSFhtGpC0cOQ=; b=Zt3/gDgY4G6qkQ0fJd9C+dwFgHIqtYpdB8h++3yqpTyvB2YMbmuGAwuWz3 bMhFuyTIGDvCcbioQic9LJ6XQbZedPH66Ddn6b80KVDbQrqciVL1AOqBvm3m dTxetKP3p5; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] bug in draft-ietf-sip-gruu-15 grammar X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 23:26:30 -0000 Hey, you mean that is actually *used*! Its nice to learn that what started out as a weird corner case or only theoretical interest actually turns up in practice! Thanks, Paul Dale Worley wrote: > On Mon, 2009-04-13 at 10:49 -0400, Paul Kyzivat wrote: >> Its been quite awhile and my memory may be getting a little fuzzy on >> this, but... >> >> As I recall there are some very subtle points about this. There are >> cases where someone other than the UA doing the registering may need the >> gruu. So the UA that registers its contact may not support GRUU, the >> gruu need be allocated so others can use it. For instance, if some other >> UA registers the same AOR, and does support gruu, it will get back all >> the contacts, and should get back gruus for all of them. Similarly, any >> who subscribe to the reg event package. > > You're correct. It was explicitly designed that the registrar would > create a GRUU even if the UA registering did not support GRUU. In > particular, this GRUU would be visible in reg events for the AoR in > question, which allows *other* UAs that want to know the GRUU of the > registering UA to find it. > > (E.g., the sipX open-source PBX takes advantage of this.) From adam@nostrum.com Mon Apr 13 17:52:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720893A68FF for ; Mon, 13 Apr 2009 17:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 RbRctxuqyHqV for ; Mon, 13 Apr 2009 17:52:07 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.15.10]) by core3.amsl.com (Postfix) with ESMTP id B525C3A68F3 for ; Mon, 13 Apr 2009 17:52:07 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3E0oStU019666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 19:50:29 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E3DDD4.1040903@nostrum.com> Date: Mon, 13 Apr 2009 19:50:28 -0500 From: Adam Roach User-Agent: Postbox 1.0b10 (Macintosh/2009032714) MIME-Version: 1.0 To: Dan Wing References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> In-Reply-To: <021601c9bc89$865e7ad0$c5f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) Cc: 'Cullen Jennings' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 00:52:08 -0000 Dan Wing wrote: > Other methods, which do not establish media -- BYE, MESSAGE, > etc. -- would receive signatures very similar to what RFC4474 > does. Namely, some certain SIP headers are signed and, if > present, the body is signed. > You're proposing signing the entire body of MESSAGE requests? But what if some intermediary, for policy reasons, wants to change the contents of a MESSAGE -- say, by redacting selected words the service provider feels are inappropriate -- without the consent of either party? ;-) /a From dwing@cisco.com Mon Apr 13 22:44:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D736928C118 for ; Mon, 13 Apr 2009 22:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDHY4VWZYh7Y for ; Mon, 13 Apr 2009 22:44:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 214BE28C129 for ; Mon, 13 Apr 2009 22:44:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238976000"; d="scan'208";a="171111811" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 14 Apr 2009 05:45:51 +0000 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 n3E5jpvN020617; Mon, 13 Apr 2009 22:45:51 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3E5jpYS000401; Tue, 14 Apr 2009 05:45:51 GMT From: "Dan Wing" To: "'Adam Roach'" References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com> Date: Mon, 13 Apr 2009 22:45:50 -0700 Message-ID: <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49E3DDD4.1040903@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm8mzmnrvq4CdZhQfyJZVr/1EK7hAAKEl0A DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=616; t=1239687951; x=1240551951; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=BUobpI+qXiI5ADUMwByWsSTv7srw3S3kPd684cpMBYQ=; b=M7btCkg9XxS/q8+R18Hj6KYkTUhchyQvq472LNqjbvSvU4de/Q7iNjdAuX 4hBleTFP0LGRTynLUeF++eyPDWLkzFC4vNb3wpRwIUOeZGrwnKxGQmJzr1OL nV+C1GZcpboEXu3fESg0Q5RkC19O+gphlxcIfTSClUYEqdqGN1bK4=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Cullen Jennings' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 05:44:40 -0000 > Dan Wing wrote: > > Other methods, which do not establish media -- BYE, MESSAGE, > > etc. -- would receive signatures very similar to what RFC4474 > > does. Namely, some certain SIP headers are signed and, if > > present, the body is signed. > > You're proposing signing the entire body of MESSAGE requests? > > But what if some intermediary, for policy reasons, wants to > change the > contents of a MESSAGE -- say, by redacting selected words the service > provider feels are inappropriate -- without the consent of > either party? > > ;-) "file system check" is spelled f-s-c-k. -d From pkyzivat@cisco.com Tue Apr 14 05:20:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87AA93A689D for ; Tue, 14 Apr 2009 05:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.155 X-Spam-Level: X-Spam-Status: No, score=-5.155 tagged_above=-999 required=5 tests=[AWL=1.444, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDYERbwWs5XU for ; Tue, 14 Apr 2009 05:20:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9F7843A67F9 for ; Tue, 14 Apr 2009 05:20:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,185,1238976000"; d="scan'208";a="285924089" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2009 12:21:13 +0000 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 n3ECLDG6004487; Tue, 14 Apr 2009 05:21:13 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3ECLCNl021408; Tue, 14 Apr 2009 12:21:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 08:21:12 -0400 Received: from [10.86.247.92] ([10.86.247.92]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 08:21:12 -0400 Message-ID: <49E47FBB.2020209@cisco.com> Date: Tue, 14 Apr 2009 08:21:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Adam Roach References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com> In-Reply-To: <49E3DDD4.1040903@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2009 12:21:12.0419 (UTC) FILETIME=[7FD41B30:01C9BCFB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=905; t=1239711673; x=1240575673; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=aXtGjIvKn8p3Ol2EQTQxqfFvbYuHAEF9XsYdjGqAAa4=; b=inimjptEXXBIPFxDke/BaJxHCvVmdkx1/yooqpJlzCPkzi7zwP3Q0vOAxh XeTqB6LVLqjtldnafOr3h5f4iWtfJ00rdiYpRrFwBxlq2f1Itm1lMndMfVOK hioiP/U0C7; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Cullen Jennings' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , Dan Wing , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 12:20:02 -0000 Adam Roach wrote: > Dan Wing wrote: >> Other methods, which do not establish media -- BYE, MESSAGE, >> etc. -- would receive signatures very similar to what RFC4474 >> does. Namely, some certain SIP headers are signed and, if >> present, the body is signed. >> > > You're proposing signing the entire body of MESSAGE requests? > > But what if some intermediary, for policy reasons, wants to change the > contents of a MESSAGE -- say, by redacting selected words the service > provider feels are inappropriate -- without the consent of either party? Surely nobody would want to do *that*! :-) Actually it is very believable. And of course the same would apply to content of an MSRP media stream. While the technology might not yet be there to do it well, I can imagine somebody wanting to impose screening on the content of audio and video media streams. Paul From apike3@csc.com Tue Apr 14 08:16:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34FD3A6A9D for ; Tue, 14 Apr 2009 08:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.92 X-Spam-Level: X-Spam-Status: No, score=-4.92 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwccS9BPaY+y for ; Tue, 14 Apr 2009 08:16:04 -0700 (PDT) Received: from mail168.messagelabs.com (mail168.messagelabs.com [216.82.253.195]) by core3.amsl.com (Postfix) with ESMTP id AF49E3A6D97 for ; Tue, 14 Apr 2009 08:15:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: apike3@csc.com X-Msg-Ref: server-5.tower-168.messagelabs.com!1239722218!9195628!2 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 16866 invoked from network); 14 Apr 2009 15:16:59 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-5.tower-168.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Apr 2009 15:16:59 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n3EFGvKS032037; Tue, 14 Apr 2009 11:16:59 -0400 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com>, <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> MIME-Version: 1.0 From: Anthony D Pike To: "Dan Wing" Message-ID: Date: Tue, 14 Apr 2009 11:16:54 -0400 X-Mailer: Lotus Domino Web Server Release 8.0.1 February 07, 2008 X-MIMETrack: Serialize by Notes Server on AMER-ML20/SRV/CSC(Release 8.0.1|February 07, 2008) at 04/14/2009 11:16:54, Serialize complete at 04/14/2009 11:16:55, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 04/14/2009 11:19:04 AM MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 'Cullen Jennings' , 'Adam Roach' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 15:16:05 -0000

This is an interesting case that Adam has brought up, and I'm sure = there are many others as well. The approach I had thought of for = this type of case is to have a second signature after the radacting ha= s taken place, so the user understands where it was changed and possibly wh= y! The original RFC 4474 signature would NOT be removed. Everytime a modifi= cation is done to the Message Request effectively a diff signature with a r= eason could be added. Unfortunately this is pretty huge burden on the UAS t= o process all the signatures if it choses to do so.

Tony

This is a PRIVATE message. If you are not the in= tended recipient, please delete without copying and kindly advise us by e-m= ail of the mistake in delivery.
NOTE: Regardless of content, this e-mai= l shall not operate to bind CSC to any order or other contract unless pursu= ant to explicit written agreement or government initiative expressly permit= ting the use of e-mail for such purpose. =E2=80=A2 


--= ---sip-bounces@ietf.org wrote: -----

To: "'Adam Roach'" <adam@nostrum.com>From: "Dan Wing" <dwing@cisco.com>
Sent by: sip-bounces@ietf.org=
Date: 04/14/2009 01:45AM
cc: "'Cullen Jennings'" <fluffy@cisco.co= m>, "'Jon Peterson'" <jon.peterson@neustar.biz>, sip@ietf.org, "'F= rancois Audet'" <audet@nortel.com>, "'DRAGE, Keith \(Keith\)'" <dr= age@alcatel-lucent.com>, "'Dean Willis'" <dean.willis@softarmor.com&g= t;
Subject: Re: [Sip] francois' comments and why RFC4474 not used in the= field


-d

=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sip mailing list  = https= ://www.ietf.org/mailman/listinfo/sip
This list is for NEW developmen= t of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for ques= tions on current sip
Use sipping@ietf.org for new developments on the ap= plication of sip

= From dwing@cisco.com Tue Apr 14 08:51:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489333A6E28 for ; Tue, 14 Apr 2009 08:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.347 X-Spam-Level: X-Spam-Status: No, score=-6.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8lrT55sPS5R for ; Tue, 14 Apr 2009 08:51:44 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 434383A6E20 for ; Tue, 14 Apr 2009 08:51:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,186,1238976000"; d="scan'208";a="153159777" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 14 Apr 2009 15:52:56 +0000 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 n3EFqt1Z025187; Tue, 14 Apr 2009 08:52:55 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3EFqtwa022951; Tue, 14 Apr 2009 15:52:55 GMT From: "Dan Wing" To: "'Anthony D Pike'" References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com>, <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> Date: Tue, 14 Apr 2009 08:52:55 -0700 Message-ID: <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> 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: Acm9FBEPojMxOyTSS1asNOK2h4zJpgAA16Gw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3557; t=1239724375; x=1240588375; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=Jjn7tvPIhnlFDpl8//rCRSMV4sMRH6853FJwr3qzMzI=; b=no9jcPBi7//nyt87/Z21UCzFsOSMhNMJd9AS+hdysKZkQ0VA2Ttv9J3D4K sjzsbi4cH8SPsY4WAuLHA7kuCGK2hkoRweaEUIS7wB4uxCteiNa9B4YRA07+ 1+5wasvzxu; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Cullen Jennings' , 'Adam Roach' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 15:51:45 -0000 > -----Original Message----- > From: Anthony D Pike [mailto:apike3@csc.com] > Sent: Tuesday, April 14, 2009 8:17 AM > To: Dan Wing > Cc: 'Adam Roach'; 'Cullen Jennings'; 'Jon Peterson'; > sip@ietf.org; 'Francois Audet'; 'DRAGE, Keith (Keith)'; 'Dean Willis' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > This is an interesting case that Adam has brought up, and I'm > sure there are many others as well. The approach I had > thought of for this type of case is to have a second > signature after the radacting has taken place, so the user > understands where it was changed and possibly why! The > original RFC 4474 signature would NOT be removed. Everytime a > modification is done to the Message Request effectively a > diff signature with a reason could be added. Unfortunately > this is pretty huge burden on the UAS to process all the > signatures if it choses to do so. Worse is the intermediaries would have to generate new public key signatures over content they are already, presumably, encrypting with TLS (I presume it's encrypted with TLS because they care about security, which is why they would be interested in additionally doing signatures over the data, too). On SIP networks today we have intermediaries modifying SDP in transit. It's happening now, on real networks. I am really interested in preserving identity over those networks. Today we do not have intermediaries modifying MESSAGE content in transit, do we? -d > Tony > > This is a PRIVATE message. If you are not the intended > recipient, please delete without copying and kindly advise us > by e-mail of the mistake in delivery. > NOTE: Regardless of content, this e-mail shall not operate to > bind CSC to any order or other contract unless pursuant to > explicit written agreement or government initiative expressly > permitting the use of e-mail for such purpose. . > > > -----sip-bounces@ietf.org wrote: ----- > > > > To: "'Adam Roach'" > From: "Dan Wing" > Sent by: sip-bounces@ietf.org > Date: 04/14/2009 01:45AM > cc: "'Cullen Jennings'" , "'Jon > Peterson'" , sip@ietf.org, > "'Francois Audet'" , "'DRAGE, Keith > \(Keith\)'" , "'Dean Willis'" > > Subject: Re: [Sip] francois' comments and why RFC4474 > not used in the field > > > Dan Wing wrote: > > > Other methods, which do not establish media -- BYE, MESSAGE, > > > etc. -- would receive signatures very similar to > what RFC4474 > > > does. Namely, some certain SIP headers are signed and, if > > > present, the body is signed. > > > > You're proposing signing the entire body of MESSAGE requests? > > > > But what if some intermediary, for policy reasons, wants to > > change the > > contents of a MESSAGE -- say, by redacting selected > words the service > > provider feels are inappropriate -- without the consent of > > either party? > > > > ;-) > > "file system check" is spelled f-s-c-k. > > -d > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sipping@ietf.org for new developments on the > application of sip > > > > = > From fluffy@cisco.com Tue Apr 14 11:46:47 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703AC3A6E47 for ; Tue, 14 Apr 2009 11:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qKLRwKLVBXu for ; Tue, 14 Apr 2009 11:46:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ADC143A6E33 for ; Tue, 14 Apr 2009 11:46:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,186,1238976000"; d="scan'208";a="286168710" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2009 18:47:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3EIlwaw001503; Tue, 14 Apr 2009 11:47:58 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3EIlua3005403; Tue, 14 Apr 2009 18:47:56 GMT From: Cullen Jennings To: Dan Wing In-Reply-To: <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com>, <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> Message-Id: <70FC04CB-9FF4-4AFC-9575-E8929756410F@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 12:47:55 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=486; t=1239734878; x=1240598878; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=dhf9nczHErjmE59NBUOpyMqeKpXp5O8W/LuOC4lPa38=; b=kaa1/mabSZqr+vKTgkcxIBgiX8ErzuLwCCoDv24ViRBvi+kqArmqyMB4pq M0BfyH0O7hrtvHRVZESlOFoSS5a3k17xfoTtCfhdYlc+newGy+eOmZ+dutZA bJPQaeREHofbb0wz7fKE/trEJQIjnjnG6az245nc7gGOOS3JJU1yE=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Adam Roach' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 18:46:47 -0000 On Apr 14, 2009, at 9:52 AM, Dan Wing wrote: > > Today we do not have intermediaries modifying MESSAGE content in > transit, do > we? Yep, systems used by financial traders often add a disclosure message to the IM as they leave the site (much like what is done for email). Systems that scan for malware in IM often replace "suspicious" content with something else. The leading IM compliance systems allow complex edits and replacements for compliance reasons. From dwing@cisco.com Tue Apr 14 11:48:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223B93A6EB9 for ; Tue, 14 Apr 2009 11:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.35 X-Spam-Level: X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kc0Uo3AGyZd for ; Tue, 14 Apr 2009 11:48:13 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6DF8F3A6DE3 for ; Tue, 14 Apr 2009 11:48:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,186,1238976000"; d="scan'208";a="171479547" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 14 Apr 2009 18:49:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3EInPLs004933; Tue, 14 Apr 2009 11:49:25 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3EInOgA007047; Tue, 14 Apr 2009 18:49:25 GMT From: "Dan Wing" To: "'Cullen Jennings'" References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com>, <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> <70FC04CB-9FF4-4AFC-9575-E8929756410F@cisco.com> Date: Tue, 14 Apr 2009 11:49:24 -0700 Message-ID: <02a501c9bd31$bb4ca7a0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <70FC04CB-9FF4-4AFC-9575-E8929756410F@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm9MYdump764WSsRAeOZxibQglLUgAABZqA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=631; t=1239734965; x=1240598965; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=qRbP3a+A97Bf8ipsIn9VPF169TALquKI/ftZt87/uSw=; b=aYjx5slgxY9W7a8xKQZ7Xd3HOD2ozj0JlSA/kzIIxcTGHda/upk/P2/+jU YTjUwOQkiQHvFOB4cK/aXdF3W70MpdQ5bLSgepG2G+4TvrqrWoePez2FNZcz S8EfNHhBOfPmG4Yb3PCxgO9Z2HVUAFQevmeAG3E1mOPK8v3dcQtu4=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Adam Roach' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 18:48:14 -0000 > On Apr 14, 2009, at 9:52 AM, Dan Wing wrote: > > > > > Today we do not have intermediaries modifying MESSAGE content in > > transit, do > > we? > > Yep, systems used by financial traders often add a disclosure > message > to the IM as they leave the site (much like what is done for email). > Systems that scan for malware in IM often replace > "suspicious" content > with something else. The leading IM compliance systems allow complex > edits and replacements for compliance reasons. Those devices are operated by their employer's systems, though. I was asking about *transit* providers. -d From dworley@nortel.com Tue Apr 14 12:44:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1DD3A6AF6 for ; Tue, 14 Apr 2009 12:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAQt2F9fUlVG for ; Tue, 14 Apr 2009 12:44:24 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BE4513A69D6 for ; Tue, 14 Apr 2009 12:44:23 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3EJiSQ09224; Tue, 14 Apr 2009 19:44:28 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 15:45:07 -0400 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <49E3CA64.1090001@cisco.com> References: <20090413025431.GB7795@florz.florz.dyndns.org> <61968779B8AC4C4BAB421D4C12F008C01C74814A@XCH47YKF.rim.net> <49E35108.4080506@cisco.com> <1239656762.5635.6.camel@victoria-pingtel-com.us.nortel.com> <49E3CA64.1090001@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 14 Apr 2009 15:45:07 -0400 Message-Id: <1239738307.4536.42.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2009 19:45:07.0597 (UTC) FILETIME=[83A1BBD0:01C9BD39] Cc: sip@ietf.org Subject: Re: [Sip] bug in draft-ietf-sip-gruu-15 grammar X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 19:44:24 -0000 On Mon, 2009-04-13 at 19:27 -0400, Paul Kyzivat wrote: > Hey, you mean that is actually *used*! > > Its nice to learn that what started out as a weird corner case or only > theoretical interest actually turns up in practice! It turns out to be useful if you are trying to accumulate "busy" status information for an AoR. In theory, you can just send a dialog event SUBSCRIBE to the AoR, but that tends to get forked to the voicemail server, etc. What you really want to do is subscribe to reg events for the AoR, and then do individual dialog event subscriptions to every contact for the AoR. That way, you're talking directly to each line-appearance of the AoR. And if you can get a GRUU for a contact, you subscribe using the GRUU rather than the stated contact URI, because that is more likely to avoid NAT problems, etc. Dale From rjsparks@nostrum.com Tue Apr 14 13:11:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118423A685F; Tue, 14 Apr 2009 13:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, SPF_PASS=-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 qpv79F-whZAZ; Tue, 14 Apr 2009 13:11:05 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 005C83A6BD1; Tue, 14 Apr 2009 13:11:01 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3EKCAq1011065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Apr 2009 15:12:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <23A205E8-C8E1-42DA-B90D-31D4A965DB17@nostrum.com> From: Robert Sparks To: SIP IETF , sipping LIST Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 15:12:10 -0500 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Sip] SIPCORE and DISPATCH have been approved - Please see the RAI list for more info X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 20:11:06 -0000 Folks - DISPATCH and SIPCORE have been approved. Please pay attention to the RAI list for more detail and discussion. RjS From dean.willis@softarmor.com Tue Apr 14 13:49:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7A628C121 for ; Tue, 14 Apr 2009 13:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 v5sWJdjmGqRK for ; Tue, 14 Apr 2009 13:49:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 151583A67F1 for ; Tue, 14 Apr 2009 13:49:27 -0700 (PDT) Received: from [192.168.2.101] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3EKob7i015701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 14 Apr 2009 15:50:38 -0500 Message-Id: <77217228-C160-43A2-84A8-4001CDC01D23@softarmor.com> From: Dean Willis To: "sip@ietf.org List" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 15:50:31 -0500 References: <941F0879-3A87-4C04-A64B-806A11B2D658@nostrum.com> X-Mailer: Apple Mail (2.930.3) Subject: [Sip] Fwd: [RAI] SIP and SIPPING X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 20:49:27 -0000 In the immortal words of Douglas Adams: So long, and thanks for all the fish! Now, where's that Vogon Constructor Fleet? -- Dean Begin forwarded message: > From: Robert Sparks > Date: April 14, 2009 3:14:37 PM CDT > To: rai@ietf.org > Subject: [RAI] SIP and SIPPING > > Now that SIPCORE and DISPATCH have been created, we are closing SIP > and SIPPING. > The charters and the previous message to the RAI list detail how > work is transitioning to the new groups. > Items that are currently with the IESG will be keeping their current > shepherds. > The mailing lists will continue to exist. From vkg@alcatel-lucent.com Tue Apr 14 13:56:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0CFF3A67F1 for ; Tue, 14 Apr 2009 13:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 f6N49vysy1p8 for ; Tue, 14 Apr 2009 13:56:45 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A02B93A659C for ; Tue, 14 Apr 2009 13:56:45 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n3EKvukM018573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 15:57:56 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n3EKvugf005622; Tue, 14 Apr 2009 15:57:56 -0500 (CDT) Message-ID: <49E4F8D4.50708@alcatel-lucent.com> Date: Tue, 14 Apr 2009 15:57:56 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis References: <941F0879-3A87-4C04-A64B-806A11B2D658@nostrum.com> <77217228-C160-43A2-84A8-4001CDC01D23@softarmor.com> In-Reply-To: <77217228-C160-43A2-84A8-4001CDC01D23@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "sip@ietf.org List" Subject: Re: [Sip] Fwd: [RAI] SIP and SIPPING X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 20:56:46 -0000 Dean Willis wrote: > In the immortal words of Douglas Adams: So long, and thanks for all the > fish! Dean: In honor of your long-standing and unflagging support for SIP, I have petitioned the city of Chicago to rename Sears Tower as "Willis" Tower. They have agreed! Please see the press bulletin that announces this name change: http://archives.chicagotribune.com/2009/mar/12/business/chi-biz-sears-tower-name-change-willis-march12 All kidding aside ... thanks for leading us from when we were wild- eyed enthusiasts in 1999 to the grizzled veterans of 2008 ;-) Ciao, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From dean.willis@softarmor.com Tue Apr 14 14:48:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4423A6859 for ; Tue, 14 Apr 2009 14:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 H5bZprtc7xSa for ; Tue, 14 Apr 2009 14:48:13 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5D85B3A63D3 for ; Tue, 14 Apr 2009 14:48:13 -0700 (PDT) Received: from [192.168.2.101] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3ELnMhQ016303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Apr 2009 16:49:23 -0500 Message-Id: <54292A09-7647-41FE-B1A9-E829D78A86AD@softarmor.com> From: Dean Willis To: "Vijay K. Gurbani" In-Reply-To: <49E4F8D4.50708@alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 16:49:15 -0500 References: <941F0879-3A87-4C04-A64B-806A11B2D658@nostrum.com> <77217228-C160-43A2-84A8-4001CDC01D23@softarmor.com> <49E4F8D4.50708@alcatel-lucent.com> X-Mailer: Apple Mail (2.930.3) Cc: "sip@ietf.org List" Subject: Re: [Sip] Fwd: [RAI] SIP and SIPPING X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 21:48:15 -0000 On Apr 14, 2009, at 3:57 PM, Vijay K. Gurbani wrote: > Dean Willis wrote: >> In the immortal words of Douglas Adams: So long, and thanks for all >> the fish! > > Dean: In honor of your long-standing and unflagging support > for SIP, I have petitioned the city of Chicago to rename > Sears Tower as "Willis" Tower. They have agreed! > > Please see the press bulletin that announces this name change: > http://archives.chicagotribune.com/2009/mar/12/business/chi-biz-sears-tower-name-change-willis-march12 > > All kidding aside ... thanks for leading us from when we were wild- > eyed enthusiasts in 1999 to the grizzled veterans of 2008 ;-) > Thanks, Vijay! It has been a privilege to lead such men (and women, and herms, and neuters, and other distinguished configurations) as these! Supposedly, the Chicago guys are my very distant cousins. Here's how it was explained to me: One of our forebears (Robert) was the personal physician of King George III (aka "the Mad", probably because of my forebear) One of his grandkids (John) went into business, owned the Cutty Sark, and lead to the Sears/Willis Tower lineage. The other (Robert again) went into engineering and became the first Dean of Engineering at Cambridge (he did a nifty writeup on the Mechanical Turk), and that's where the name Dean entered the family tree. My father was George, after the king, and his father was Robert Dean. His father was George Dean, and so on. So, the Willis Tower really is named after me. Sort of. Of course, this could all just be a long line my mother once heard from my father, and from which I am therefore descended only verbally. -- Dean From adam@nostrum.com Tue Apr 14 15:21:07 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926033A6A86 for ; Tue, 14 Apr 2009 15:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 GC7RKmKMW3UC for ; Tue, 14 Apr 2009 15:21:06 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 735FC3A6895 for ; Tue, 14 Apr 2009 15:21:06 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3EMMBEr068566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 17:22:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E50C93.5060806@nostrum.com> Date: Tue, 14 Apr 2009 17:22:11 -0500 From: Adam Roach User-Agent: Postbox 1.0b10 (Macintosh/2009032714) MIME-Version: 1.0 To: Anthony D Pike References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com>, <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090902040802090804010105" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: 'Cullen Jennings' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , Dan Wing , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 22:21:07 -0000 This is a multi-part message in MIME format. --------------090902040802090804010105 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Anthony D Pike wrote: > > This is an interesting case that Adam has brought up, and I'm sure > there are many others as well. The approach I had thought of for this > type of case is to have a second signature after the radacting has > taken place, so the user understands where it was changed and possibly > why! The original RFC 4474 signature would NOT be removed. Everytime a > modification is done to the Message Request effectively a diff > signature with a reason could be added. > Yep. And that would work with SDP in INVITES, too. > Unfortunately this is pretty huge burden on the UAS to process all the > signatures if it choses to do so. > Not really -- performing three or four crypto operations shouldn't slow down a terminal more than a trivial amount. And, of course (as you point out), it doesn't *need* to actually process the signatures. /a --------------090902040802090804010105 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Anthony D Pike wrote:

This is an interesting case that Adam has brought up, and I'm sure there are many others as well. The approach I had thought of for this type of case is to have a second signature after the radacting has taken place, so the user understands where it was changed and possibly why! The original RFC 4474 signature would NOT be removed. Everytime a modification is done to the Message Request effectively a diff signature with a reason could be added.


Yep. And that would work with SDP in INVITES, too.

Unfortunately this is pretty huge burden on the UAS to process all the signatures if it choses to do so.


Not really -- performing three or four crypto operations shouldn't slow down a terminal more than a trivial amount. And, of course (as you point out), it doesn't *need* to actually process the signatures.

/a
--------------090902040802090804010105-- From adam@nostrum.com Tue Apr 14 15:58:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA873A6A29 for ; Tue, 14 Apr 2009 15:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 fH8161I+3S9w for ; Tue, 14 Apr 2009 15:58:02 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B40A63A6ACA for ; Tue, 14 Apr 2009 15:58:01 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3EMx7Tv033493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 17:59:07 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E5153B.8020501@nostrum.com> Date: Tue, 14 Apr 2009 17:59:07 -0500 From: Adam Roach User-Agent: Postbox 1.0b10 (Macintosh/2009032714) MIME-Version: 1.0 To: Dan Wing References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com>, <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> In-Reply-To: <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> Content-Type: multipart/alternative; boundary="------------010308010607040900010501" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: 'Cullen Jennings' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 22:58:03 -0000 This is a multi-part message in MIME format. --------------010308010607040900010501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [with my individual contributor hat on] Dan Wing wrote: > On SIP networks today we have intermediaries modifying SDP in transit. It's > happening now, on real networks. I am really interested in preserving > identity over those networks. > And I have HTTP proxies that I'd love to send RTP through. At some point, we've got to realize that certain types of old dogs aren't even remotely suited for particularly demanding new tricks -- at least, not without software upgrades. I think it's important to distinguish among three classes of solutions in this space: 1. Identity that works through existing B2BUAs 2. Identity that might not work through existing B2BUAs, but that B2BUAs can be modified to work with 3. Identity that precludes the presence of B2BUAs There are clearly approaches that fit into each of these three categories. There are a number of people (and I count myself among them) who find the security properties of the proposals that fit into #1 to be odious. There are also people who clearly find proposals in class #3 unacceptable for their lack of pragmatism. Now, there are also a number of people who have historically staked out extremist positions that state that only solutions in category #1 (or only solutions in category #3) are acceptable, and that neither of the other two options could possibly be acceptable. I think we need to ignore people arguing from either of these extreme positions, because their positions are mutually exclusive, and can never be rectified with each other. At the risk of suggesting compromise, I'll point out that there *is* a way to mutually satisfy those people who reject solutions in class #1 and those people who reject solutions in class #3. I suspect that useful progress lies in that direction only. /a --------------010308010607040900010501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [with my individual contributor hat on]

Dan Wing wrote: 
On SIP networks today we have intermediaries modifying SDP in transit.  It's
happening now, on real networks.  I am really interested in preserving
identity over those networks.

And I have HTTP proxies that I'd love to send RTP through. At some point, we've got to realize that certain types of old dogs aren't even remotely suited for particularly demanding new tricks -- at least, not without software upgrades.

I think it's important to distinguish among three classes of solutions in this space:

  1. Identity that works through existing B2BUAs
  2. Identity that might not work through existing B2BUAs, but that B2BUAs can be modified to work with
  3. Identity that precludes the presence of B2BUAs

There are clearly approaches that fit into each of these three categories. There are a number of people (and I count myself among them) who find the security properties of the proposals that fit into #1 to be odious. There are also people who clearly find proposals in class #3 unacceptable for their lack of pragmatism.

Now, there are also a number of people who have historically staked out extremist positions that state that only solutions in category #1 (or only solutions in category #3) are acceptable, and that neither of the other two options could possibly be acceptable. I think we need to ignore people arguing from either of these extreme positions, because their positions are mutually exclusive, and can never be rectified with each other.

At the risk of suggesting compromise, I'll point out that there *is* a way to mutually satisfy those people who reject solutions in class #1 and those people who reject solutions in class #3. I suspect that useful progress lies in that direction only.

/a
--------------010308010607040900010501-- From jon.peterson@neustar.biz Tue Apr 14 16:06:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6143A6A29 for ; Tue, 14 Apr 2009 16:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 O-P4EkOXxiKZ for ; Tue, 14 Apr 2009 16:06:05 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id AB6E23A6B90 for ; Tue, 14 Apr 2009 16:05:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1239750421; x=1239836821; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=glez+igIY1d3MKMSwONMmPFBDFeo4d5giUSAh6fqugAqYjmCHB2gL6rvAQOjiI+4BQs6fz1sqIlrPH Om5Rj88g== Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.13007856; Tue, 14 Apr 2009 19:06:43 -0400 Received: from 10.31.13.108 ([10.31.13.108]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Apr 2009 23:06:42 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 14 Apr 2009 16:06:42 -0700 From: Jon Peterson To: Dan Wing , 'Francois Audet' , "'Elwell, John'" , Dean Willis Message-ID: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sABO07UAACAyOlAJLdPdAAAaBeFgAAfZ3wAAGstvYABvrh8AAzKBrI In-Reply-To: <021601c9bc89$865e7ad0$c5f0200a@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 23:06:06 -0000 On 4/13/09 3:45 PM, "Dan Wing" wrote: >> I have a hard time seeing how anything we >> do at the media layer is salient to that - again, just speaking to high >> level examples, if you accept a forged BYE request, > > The BYE would be protected from forgery sufficient to detect a > forgery, using mechanisms like RFC4474 protects a BYE from > forgery: signing enough SIP headers to block a forgery. In so far as there's really any thrust to my argument here, it's that the situation of an INVITE that an attacker never intends to use to establish a session is comparable to that of a BYE - one must sign enough of its headers to detect a forgery to thwart its mischief. The problem is, of course, that there's no way for the security mechanism to differentiate these sorts of INVITEs from the "sunny day" session-establishment cases where media-layer security will eventually be invoked, which makes me question exactly how much we can reduce the set of INVITE headers we sign. This doesn't mean I object fundamentally to a two-pronged solution; say, signing set X of fields for all requests with an SDP body and set Y for all requests without an SDP body. It just means that in the threat model I'm considering, I have reservations about making X much smaller than Y. Jon Peterson NeuStar, Inc. >> that will presumably >> convince you to tear down a call regardless of anything that media-layer >> security has established. I've argued a similar requirement exists to >> prevent a forged re-INVITE that just sets the IP/port to >> something useless. From dwing@cisco.com Tue Apr 14 16:09:39 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F199D3A6B91 for ; Tue, 14 Apr 2009 16:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.355 X-Spam-Level: X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXy-QFeDt0xQ for ; Tue, 14 Apr 2009 16:09:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id EFD123A6B90 for ; Tue, 14 Apr 2009 16:09:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,188,1238976000"; d="scan'208";a="154685296" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2009 23:10:51 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3ENAoJm018626; Tue, 14 Apr 2009 16:10:50 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3ENAoKD010123; Tue, 14 Apr 2009 23:10:50 GMT From: "Dan Wing" To: "'Adam Roach'" References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com>, <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> <49E5153B.8020501@nostrum.com> Date: Tue, 14 Apr 2009 16:10:47 -0700 Message-ID: <03df01c9bd56$3eb18bf0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49E5153B.8020501@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm9VJ+kIPK/lafbSQqCtbwY7iH8sAAALsnw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2653; t=1239750651; x=1240614651; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=H+7CYg+cZCfRclJtTt2sxG9vTdfPAW35oZti244o5YM=; b=YUXqOwQw/cVKpc9yZ+K6EPI94MgXVgZjiw+s91RGjPEqMlZ5EVlS/UkJes AagYZKENkG0meptlK70BdotE1i1V6brKFwCAtJ58dZWD9s2mnusKsfMJkAtu 2tw5skI1qu; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Cullen Jennings' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 23:09:40 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, April 14, 2009 3:59 PM > To: Dan Wing > Cc: 'Anthony D Pike'; 'Cullen Jennings'; 'Jon Peterson'; > sip@ietf.org; 'Francois Audet'; 'DRAGE, Keith (Keith)'; 'Dean Willis' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > [with my individual contributor hat on] > > Dan Wing wrote: > > On SIP networks today we have intermediaries modifying > SDP in transit. It's > happening now, on real networks. I am really > interested in preserving > identity over those networks. > > > > And I have HTTP proxies that I'd love to send RTP through. At > some point, we've got to realize that certain types of old > dogs aren't even remotely suited for particularly demanding > new tricks -- at least, not without software upgrades. > > I think it's important to distinguish among three classes of > solutions in this space: > > > > 1. Identity that works through existing B2BUAs > 2. Identity that might not work through existing B2BUAs, > but that B2BUAs can be modified to work with > 3. Identity that precludes the presence of B2BUAs > > > There are clearly approaches that fit into each of these > three categories. There are a number of people (and I count > myself among them) who find the security properties of the > proposals that fit into #1 to be odious. There are also > people who clearly find proposals in class #3 unacceptable > for their lack of pragmatism. > > Now, there are also a number of people who have historically > staked out extremist positions that state that only solutions > in category #1 (or only solutions in category #3) are > acceptable, and that neither of the other two options could > possibly be acceptable. I think we need to ignore people > arguing from either of these extreme positions, because their > positions are mutually exclusive, and can never be rectified > with each other. > > At the risk of suggesting compromise, I'll point out that > there *is* a way to mutually satisfy those people who reject > solutions in class #1 and those people who reject solutions > in class #3. I suspect that useful progress lies in that > direction only. Agreed. And I also prefer #2. There have been 3 solutions on the table that provide e2e identity with small changes to those B2BUAs (essentially: permit such-and-such header fields to pass), and accomplish this without an appreciable CPU impact on those intermediaries. All three of those proposals are in the #2 category. -d From dwing@cisco.com Tue Apr 14 16:32:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8249F3A6B3C for ; Tue, 14 Apr 2009 16:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.36 X-Spam-Level: X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxPhZnDKyww9 for ; Tue, 14 Apr 2009 16:32:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7FDF23A6E37 for ; Tue, 14 Apr 2009 16:32:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,188,1238976000"; d="scan'208";a="286317860" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2009 23:33:54 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3ENXs4s031613; Tue, 14 Apr 2009 16:33:54 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3ENXsGs002020; Tue, 14 Apr 2009 23:33:54 GMT From: "Dan Wing" To: "'Jon Peterson'" , "'Francois Audet'" , "'Elwell, John'" , "'Dean Willis'" References: <021601c9bc89$865e7ad0$c5f0200a@cisco.com> Date: Tue, 14 Apr 2009 16:33:49 -0700 Message-ID: <03f301c9bd59$76c6d150$c5f0200a@cisco.com> 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: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sABO07UAACAyOlAJLdPdAAAaBeFgAAfZ3wAAGstvYABvrh8AAzKBrIAADvo+A= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2150; t=1239752034; x=1240616034; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=vDhx1C3jy14IuHPIC0UFS4rBW75c0TY+ZpQ9/Yhhsdo=; b=KD9iD4+8cbKeuR0vt/Q5UiuVlEPWi4aHCwbm52CeaVA99epcxATNnm0yPk 7Yksbnv1v7ogwkB7ywrB0zQjavb9fvk7sa1xbSn2qGlJRM684skv+g+2lHqc wmAy++Mo+j; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Cullen Jennings' , sip@ietf.org, "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 23:32:43 -0000 > -----Original Message----- > From: Jon Peterson [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, April 14, 2009 4:07 PM > To: Dan Wing; 'Francois Audet'; 'Elwell, John'; Dean Willis > Cc: Cullen Jennings; sip@ietf.org; 'DRAGE,Keith (Keith)' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > On 4/13/09 3:45 PM, "Dan Wing" wrote: > > >> I have a hard time seeing how anything we > >> do at the media layer is salient to that - again, just > speaking to high > >> level examples, if you accept a forged BYE request, > > > > The BYE would be protected from forgery sufficient to detect a > > forgery, using mechanisms like RFC4474 protects a BYE from > > forgery: signing enough SIP headers to block a forgery. > > In so far as there's really any thrust to my argument here, > it's that the > situation of an INVITE that an attacker never intends to use > to establish a > session is comparable to that of a BYE - one must sign enough > of its headers > to detect a forgery to thwart its mischief. The problem is, > of course, that > there's no way for the security mechanism to differentiate > these sorts of > INVITEs from the "sunny day" session-establishment cases > where media-layer > security will eventually be invoked, which makes me question > exactly how > much we can reduce the set of INVITE headers we sign. > > This doesn't mean I object fundamentally to a two-pronged > solution; say, > signing set X of fields for all requests with an SDP body and > set Y for all > requests without an SDP body. It just means that in the > threat model I'm > considering, I have reservations about making X much smaller than Y. Yes, I agree we need to sign enough headers to prevent an attack. -d > Jon Peterson > NeuStar, Inc. > > >> that will presumably > >> convince you to tear down a call regardless of anything > that media-layer > >> security has established. I've argued a similar > requirement exists to > >> prevent a forged re-INVITE that just sets the IP/port to > >> something useless. > From fluffy@cisco.com Tue Apr 14 16:46:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412A83A6898 for ; Tue, 14 Apr 2009 16:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUyx5aSk8a0k for ; Tue, 14 Apr 2009 16:46:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 649983A6B2B for ; Tue, 14 Apr 2009 16:45:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,188,1238976000"; d="scan'208";a="286324378" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2009 23:47:01 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3ENl15v022535; Tue, 14 Apr 2009 16:47:01 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3ENkxgd005792; Tue, 14 Apr 2009 23:47:00 GMT From: Cullen Jennings To: Dan Wing (dwing) In-Reply-To: <02a501c9bd31$bb4ca7a0$c5f0200a@cisco.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com>, <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> <70FC04CB-9FF4-4AFC-9575-E8929756410F@cisco.com> <02a501c9bd31$bb4ca7a0$c5f0200a@cisco.com> Message-Id: <69C61993-2D69-45F5-A0E8-AA841AFC4251@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 17:46:59 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=844; t=1239752821; x=1240616821; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=S/JvJa2IR1XE4S7jOY/249KwVfDaD9g7ljohfet8LME=; b=SuSxYcyNyxZ/TDx0dPYxPKdq5xjdRf5BDBgSsTwkiNtjkvzbaADcn3CaHg iSkWqSNVQLrmfJ9FEMvuA/WNk4CwLUBy8JkWmA7epln7uW7U/ntRglUS5sG/ slec1qK04itU0j4B+81Q5MrJOQgev8tbAc6CusPg4ZzxLaaeyE9+o=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Adam Roach , Jon Peterson , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 23:46:05 -0000 On Apr 14, 2009, at 12:49 PM, Dan Wing (dwing) wrote: > > On Apr 14, 2009, at 9:52 AM, Dan Wing wrote: > > > > > > > > Today we do not have intermediaries modifying MESSAGE content in > > > transit, do > > > we? > > > > Yep, systems used by financial traders often add a disclosure > > message > > to the IM as they leave the site (much like what is done for email). > > Systems that scan for malware in IM often replace > > "suspicious" content > > with something else. The leading IM compliance systems allow complex > > edits and replacements for compliance reasons. > > Those devices are operated by their employer's systems, though. I > was asking about *transit* providers. > > > Yah, I don't know if some the IM federation groups do that type of thing in the middle or if it is all done at the edge. > From munjo.yu@gmail.com Tue Apr 14 16:47:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E7E3A6E62; Tue, 14 Apr 2009 16:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 6DAL9V9hfBWJ; Tue, 14 Apr 2009 16:47:45 -0700 (PDT) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by core3.amsl.com (Postfix) with ESMTP id 74CB83A68E1; Tue, 14 Apr 2009 16:47:45 -0700 (PDT) Received: by qyk40 with SMTP id 40so1609474qyk.29 for ; Tue, 14 Apr 2009 16:48:54 -0700 (PDT) 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=Et0TtATIlmxh9s2/bNPfx857RmKcAulsxqVO1DJkRx0=; b=OT9DkdbhsPdk3G0DSVzrxSbVl6oJgEZR6P7NObV3sdK6UeC7HQAoZZYf6NW6mhFw8G cXRLOgJK1Ss5fgw5waDSfsLbkuWgnG6EGh/xtP6EBn4+G/WeJOSztpDXXkmu6PfNIOqd fk255er8fMdCcoNhXmzAyWa1W/j3L6EMb0/X4= 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=tCx0THwIFh0YR/255D1JTVflwNPbQ/+Wpuy95dA2NkaX0/JDvcAssrQzPFNzxMdnyE OrhKLCeTVbjJQnE2HKk2Hi04QhxMCAGRfYA8HfnYEOSi9hEIENEiwUze0BqIJBE9WbVB +3bQrdqWAIuMycfUhVSONuxVFHDrHaeXb7CnA= MIME-Version: 1.0 Received: by 10.229.109.194 with SMTP id k2mr2325779qcp.6.1239752934137; Tue, 14 Apr 2009 16:48:54 -0700 (PDT) In-Reply-To: <1239400601.3742.71.camel@victoria-pingtel-com.us.nortel.com> References: <1239400601.3742.71.camel@victoria-pingtel-com.us.nortel.com> Date: Tue, 14 Apr 2009 19:48:54 -0400 Message-ID: From: Munjo Yu To: Dale Worley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, apps-discuss@ietf.org Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 23:47:46 -0000 Hi all, again. We find two keywords from the responses. - trade-off between features and simplicity - ambiguities in Set These two may well have been the main reasons why Set was dropped from the draft 3 (http://tools.ietf.org/html/draft-ietf-drums-abnf-03) about 12 years ago. Since then, Internet flourished and so did protocols. Along the line, the pivot for trading off might have shifted towards "features" from "simplicity" a little bit, we wonder. And we still hope that overall gain from adding "Set" might be positive. The biggest advantage of introducing Set again is: - self-contained definitions in describing a message whose components can come unordered. - more readability - far better for parser generation And of course, we sacrifice its simplicity, a little bit. The following is a writing of Set specifications. We are looking forward to hearing overall integrity concerns, among other things. 3.6. Variable Repetition: *Rule . . 3.6.1. Element's Repetition in Sequence, Concatenation, etc, other than Set An element with a repetition is expanded sequentially. Example: Element's Repetition in non-Set types which results in forming a Sequence group 3A =3D (A A A) So, ... Example: Sequence Group in a Set set =3D {(3A) X} =3D {(A A A) X} =3D ((A A A) X)/ (X (A A A)) =3D (A A A X) / (X A A A) Example: Sequence Group in Set set =3D {(A B C) X} =3D (A B C X) / (X A B C) 3.6.2. Element's Repetition in Set An element with a repetition in a Set is expanded non-sequentially. Example: Element's Repetition in Set set =3D {3A X} =3D {A A A X} =3D (A A A X) / (A A X A) / (A X A A) / (X A A A) 3.6.3. Set's Repetition A Set with a repetition is expanded only atomically. Example: SETa =3D {A B} 2SETa =3D 2{A B} =3D 2((A B)/(B A)) =3D ((A B) (A B)) / ((B A) (B A)) =3D (A B A B) / (B A B A) ******************** 4. ABNF Definition of ABNF . . element =3D rulename / group / set / option / char-val / num-val / prose-val set =3D "{" repetition *(1*c-wsp repetition ) "}" ; repetitions in any order Note that the rule "element" above now includes "set" and the rule set is of course the new addition for Set. In addition to probing into this new specifications, please raise a red flag for any possible disruptions of existing RFCs by this new Set, even though we are pretty sure that no existing specifications would be affected by this change. Thanks, -Munjo Yu, VineGen Inc. On Fri, Apr 10, 2009 at 5:56 PM, Dale Worley wrote: > On Wed, 2009-04-01 at 20:17 -0500, Munjo Yu wrote: >> SET is described simply as follows, using a pair of braces: >> >> SET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {Rule1 Rule2= } > > As a start, I would like to see a fully accurate description of how the > SET construction is written, and what its significance is. =A0Given that > SET is a *tool for writing specifications*, we must be careful to define > it exactly. =A0Currently, all we have is one example of its use. > > Dale > > > From adam@nostrum.com Tue Apr 14 19:17:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7B83A69FA for ; Tue, 14 Apr 2009 19:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 IX+1DEahSy1s for ; Tue, 14 Apr 2009 19:17:13 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 396683A6855 for ; Tue, 14 Apr 2009 19:17:12 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3F2II9Z010129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 21:18:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E543EA.4090206@nostrum.com> Date: Tue, 14 Apr 2009 21:18:18 -0500 From: Adam Roach User-Agent: Postbox 1.0b10 (Macintosh/2009032714) MIME-Version: 1.0 To: Dan Wing References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com>, <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> <49E5153B.8020501@nostrum.com> <03df01c9bd56$3eb18bf0$c5f0200a@cisco.com> In-Reply-To: <03df01c9bd56$3eb18bf0$c5f0200a@cisco.com> Content-Type: multipart/alternative; boundary="------------040804040709070708050108" Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) Cc: 'Cullen Jennings' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 02:17:14 -0000 This is a multi-part message in MIME format. --------------040804040709070708050108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dan Wing wrote: >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> ... >> Dan Wing wrote: >> >> On SIP networks today we have intermediaries modifying >> SDP in transit. It's >> happening now, on real networks. I am really >> interested in preserving >> identity over those networks. >> >> ... >> >> I think it's important to distinguish among three classes of >> solutions in this space: >> >> 1. Identity that works through existing B2BUAs >> 2. Identity that might not work through existing B2BUAs, >> but that B2BUAs can be modified to work with >> 3. Identity that precludes the presence of B2BUAs >> >> ... >> >> At the risk of suggesting compromise, I'll point out that >> there *is* a way to mutually satisfy those people who reject >> solutions in class #1 and those people who reject solutions >> in class #3. I suspect that useful progress lies in that >> direction only. >> > > Agreed. And I also prefer #2. Ah, I misunderstood your earlier statement -- "I am really interested in preserving identity over [SIP networks today with intermediaries that modify SDP in transit]" -- to mean that the intermediaries were not to be modified. So we're really both talking about SIP networks for some upcoming tomorrow, not SIP networks today. Good. I think that leaves a lot of common ground to work with. /a --------------040804040709070708050108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan Wing wrote: 
-----Original Message-----
From: Adam Roach [mailto:adam@nostrum.com] 
...
Dan Wing wrote: 

	On SIP networks today we have intermediaries modifying 
SDP in transit.  It's
	happening now, on real networks.  I am really 
interested in preserving
	identity over those networks.

...

I think it's important to distinguish among three classes of 
solutions in this space:

1.	Identity that works through existing B2BUAs
2.	Identity that might not work through existing B2BUAs, 
but that B2BUAs can be modified to work with
3.	Identity that precludes the presence of B2BUAs

...

At the risk of suggesting compromise, I'll point out that 
there *is* a way to mutually satisfy those people who reject 
solutions in class #1 and those people who reject solutions 
in class #3. I suspect that useful progress lies in that 
direction only.
    

Agreed.  And I also prefer #2.


Ah, I misunderstood your earlier statement --  "I am really interested in preserving identity over [SIP networks today with intermediaries that modify SDP in transit]" -- to mean that the intermediaries were not to be modified. So we're really both talking about SIP networks for some upcoming tomorrow, not SIP networks today.

Good. I think that leaves a lot of common ground to work with.

/a
--------------040804040709070708050108-- From AUDET@nortel.com Tue Apr 14 20:40:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464F53A688A for ; Tue, 14 Apr 2009 20:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.347 X-Spam-Level: X-Spam-Status: No, score=-6.347 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wan1hx5mvXFj for ; Tue, 14 Apr 2009 20:40:47 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 269453A659C for ; Tue, 14 Apr 2009 20:40:47 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3F3eeZ03310; Wed, 15 Apr 2009 03:40:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BD7C.09E82F81" Date: Tue, 14 Apr 2009 22:41:17 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D70CFFA@zrc2hxm0.corp.nortel.com> In-Reply-To: <49E543EA.4090206@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acm9cHeQYandl9rlQOOT0v1Zr1HE2gACr9XA References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com>, <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> <49E5153B.8020501@nostrum.com> <03df01c9bd56$3eb18bf0$c5f0200a@cisco.com> <49E543EA.4090206@nostrum.com> From: "Francois Audet" To: "Adam Roach" , "Dan Wing" Cc: Cullen Jennings , Jon Peterson , sip@ietf.org, "DRAGE, Keith \(Keith\)" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 03:40:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BD7C.09E82F81 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I really think the real point is not "preserving existing SBC behavior" = or "preserving 4474 behavior". =20 It seems to me the real point that is being made is that perhaps there = is a way to have a useful Identity mechanism, even while allowing IP = addresses and ports to be modified in transit, provided that there is a = sufficient mechanism for allowing (1) the media to integrity protected, = (2) the media to be correlated to the identity, and (3) allowing for = detection media being "cut". =20 I believe Jon was saying that furthermore, it must be detectable if the = IP address and port was modified in transit. I'm not completly clear why = it's necessary if all the conditions above are met. Maybe it's part of = (3). ________________________________ From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, April 14, 2009 19:18 To: Dan Wing Cc: 'Anthony D Pike'; 'Cullen Jennings'; 'Jon Peterson'; sip@ietf.org; = Audet, Francois (SC100:3055); 'DRAGE, Keith (Keith)'; 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the = field =09 =09 Ah, I misunderstood your earlier statement -- "I am really interested = in preserving identity over [SIP networks today with intermediaries that = modify SDP in transit]" -- to mean that the intermediaries were not to = be modified. So we're really both talking about SIP networks for some = upcoming tomorrow, not SIP networks today. =09 Good. I think that leaves a lot of common ground to work with. =09 /a =09 ------_=_NextPart_001_01C9BD7C.09E82F81 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 really think the real point is not "preserving existing SBC behavior" or = "preserving 4474 behavior".
 
It=20 seems to me the real point that is being made is that perhaps there is a = way to=20 have a useful Identity mechanism, even while allowing IP addresses and = ports to=20 be modified in transit, provided that there is a sufficient mechanism = for=20 allowing (1) the media to integrity protected, (2) the media to be = correlated to=20 the identity, and (3) allowing for detection media being=20 "cut".
 
I=20 believe Jon was saying that furthermore, it must be detectable if the IP = address=20 and port was modified in transit. I'm not completly clear why it's = necessary if=20 all the conditions above are met. Maybe it's part of=20 (3).

From: Adam Roach = [mailto:adam@nostrum.com]=20
Sent: Tuesday, April 14, 2009 19:18
To: Dan=20 Wing
Cc: 'Anthony D Pike'; 'Cullen Jennings'; 'Jon = Peterson';=20 sip@ietf.org; Audet, Francois (SC100:3055); 'DRAGE, Keith (Keith)'; = 'Dean=20 Willis'
Subject: Re: [Sip] francois' comments and why = RFC4474 not=20 used in the field

Ah, I misunderstood your earlier statement --  "I am = really=20 interested in preserving identity over [SIP networks today with = intermediaries=20 that modify SDP in transit]" -- to mean that the intermediaries were = not to be=20 modified. So we're really both talking about SIP networks for some = upcoming=20 tomorrow, not SIP networks today.

Good. I think that leaves a = lot of=20 common ground to work with.

/a
------_=_NextPart_001_01C9BD7C.09E82F81-- From dwing@cisco.com Tue Apr 14 21:06:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248B43A684C for ; Tue, 14 Apr 2009 21:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52o3ayda3PGY for ; Tue, 14 Apr 2009 21:06:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3570E3A6B0F for ; Tue, 14 Apr 2009 21:06:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,189,1238976000"; d="scan'208";a="33800145" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 15 Apr 2009 04:07:17 +0000 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 n3F47F5n009000; Tue, 14 Apr 2009 21:07:15 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3F47Fnb025312; Wed, 15 Apr 2009 04:07:15 GMT From: "Dan Wing" To: "'Adam Roach'" References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com>, <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> <49E5153B.8020501@nostrum.com> <03df01c9bd56$3eb18bf0$c5f0200a@cisco.com> <49E543EA.4090206@nostrum.com> Date: Tue, 14 Apr 2009 21:07:15 -0700 Message-ID: <045301c9bd7f$a9653bd0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49E543EA.4090206@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acm9cHOWZU+Y9PyoQYiW5cNu+Pz+lgADxCpA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2102; t=1239768435; x=1240632435; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=toFtBAirXd/NcMHpaNnbhHmEk3bb83zBReX3Xx4FhwM=; b=OUa99EAE9MdzaWsKtjqQhjIkTLwrurYAjUa6PO3OMiGTFTw6HM1FJCTsUq GkXbKpqZ0c6WjewDGtsGYv/g+T9dy1QlRXZAb+3kJvu79oUp54PIg2Ajjmzr pmKIiG4CWf; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Cullen Jennings' , 'Jon Peterson' , sip@ietf.org, 'Francois Audet' , "'DRAGE, Keith \(Keith\)'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 04:06:06 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, April 14, 2009 7:18 PM > To: Dan Wing > Cc: 'Anthony D Pike'; 'Cullen Jennings'; 'Jon Peterson'; > sip@ietf.org; 'Francois Audet'; 'DRAGE, Keith (Keith)'; 'Dean Willis' > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > Dan Wing wrote: > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > ... > Dan Wing wrote: > > On SIP networks today we have > intermediaries modifying > SDP in transit. It's > happening now, on real networks. I am really > interested in preserving > identity over those networks. > > ... > > I think it's important to distinguish among > three classes of > solutions in this space: > > 1. Identity that works through existing B2BUAs > 2. Identity that might not work through > existing B2BUAs, > but that B2BUAs can be modified to work with > 3. Identity that precludes the presence of B2BUAs > > ... > > At the risk of suggesting compromise, I'll > point out that > there *is* a way to mutually satisfy those > people who reject > solutions in class #1 and those people who > reject solutions > in class #3. I suspect that useful progress > lies in that > direction only. > > > > Agreed. And I also prefer #2. > > > > Ah, I misunderstood your earlier statement -- "I am really > interested in preserving identity over [SIP networks today > with intermediaries that modify SDP in transit]" -- to mean > that the intermediaries were not to be modified. So we're > really both talking about SIP networks for some upcoming > tomorrow, not SIP networks today. I'm talking about SIP networks that adjust SDP, and which can be convinced to pass along some additional SIP headers. I have been told, in the past, that I'm having a pipe dream when I suggest that. -d > Good. I think that leaves a lot of common ground to work with. > > /a > > From dean.willis@softarmor.com Tue Apr 14 21:35:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B37728C102 for ; Tue, 14 Apr 2009 21:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 0TvT4ROYTcVJ for ; Tue, 14 Apr 2009 21:35:33 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D8AD528C0E3 for ; Tue, 14 Apr 2009 21:35:32 -0700 (PDT) Received: from [192.168.2.101] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3F4abkP018885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Apr 2009 23:36:39 -0500 Message-Id: <3A32058B-C678-439A-A231-34D53C9C5A78@softarmor.com> From: Dean Willis To: "sip@ietf.org List" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 23:36:32 -0500 X-Mailer: Apple Mail (2.930.3) Cc: Gonzalo Camarillo , Keith Drage , Mary Barnes Subject: [Sip] Draft SIP minutes for IETF 74 posted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 04:35:34 -0000 See: http://www.softarmor.com/mediawiki/index.php/Minutes_for_SIP_at_IETF_74 A text-paste follows (original has HTML markup for clarity). ------------------------ Minutes for SIP at IETTF 74Session 1, SIPCORE-like topicsAgenda BashLed by Chairs Slides presented and included in minutes Agenda accepted as presented. SIP Forum configuration profile work mentioned, interested people invited to Wednesday breakfast. Current status of WG documents reviewed. Topic: SIP Change Process IntroLed by: Jon Peterson draft-peterson-rai-rfc3427bis-01 Slides presented and included in minutes Reviewed IETF LC status of RFC32427bis and invited comments at IETF level. Issue: SIPCORE scope Spencer Dawkins suggested that the charter text should include discussion about ADs being able to make judgement calls on SIPCORE charter items as needed. Issue: DISPATCH scope Discussion centered on defining the deliverables of SIPCORE and the need to get small things done somewhere. Issue: Deliverables of DISPATCH Agreed that DISPATCH will deliver neither Proposed Standards nor protocol specifications. Deliverables might include problem statements, draft charters, or work plans for non-WG BOFs such as was used for the media security requirements work. DISPATCH will not work like TSVWG, and will not act as a "product manager" serving requirements to the SIPCORE "engineers", but may direct work items towards working groups without placing any requirement on that WG to actually do the work. Issue: Where to do small work items It is envisioned that mall work items can be done in BOF-like formats or through individual efforts, and pushed through as AD-sponsored non- WG drafts. Issue: Time required to launch a new WG We do not expect a mechanism whereby requirements can be brought into a DISPATCH meeting and result in a new WG formed at the next IETF meeting. Rather, the traditional BOF process is anticipated to apply. Issue: P-headers and Existing Work In Progress Several in-process drafts define p-headers. This will proceed without change. Further new work will NOT define p-headers; rather each header will be tagged as to its status in the registry. Topic: Early Dialog terminationLed by: Christer Holmberg draft-ietf-sip-199-02 Slides presented and included in minutes Some discussion occurred on reliable transmission and B2BUA interactions. There was apparently a long on-list discussion that resulted in the current text. ISsue: Are we ready for WGLC? Chair noted that previous WGLC resulted in many new issues, and that he would like to see closure on those issues before renewing the last call. Chair is to make a new call on-list, and if there are no reports of remaining open issues, the chair will issue a new WGLC. Topic: 3261 Interop StatementLed by: Robert Sparks draft-sparks-sip-3261-interop-statement-00 No slides presented. Proposed that the reference document will be placed on-line and maintained as a living document. Also proposed that the interop statement document can be used to build an evaluation tool for use at SIPit. No objections to this approach were noted. Topic: 3261 Normative ReferencesLed by: Robert Sparks draft-sparks-sip-3261-norm-ref-status-00 No slides presented. Status of work was presented, with no discussion or issues noted from attendees. Topic: Fix INVITE transactionLed by: Robert Sparks draft-sparks-sip-invfix-03 Slides presented and included in minutes Theo Zourzouvillys will be acting as editor for this document. Issue: Does the increase in state size (for accepted) break things? Robert noted that much of draft was driven by working implementations at SIPit, so this is not expected to be a major issue. However, it should be noted that this approach does significantly increase the amount of transaction state kept in proxies. Topic: RFC 4244bisLed by: Francois Audet draft-barnes-sip-rfc4244bis-00 draft-rosenberg-sip-target-uri-delivery-00 Slides presented and included in minutes Initial discussion reviewed the changes to the document, and discussed whether resolving the security concerns of RFC 4244 are in-scope. Issue: Naming semantics We have a number of names like retargeting, rerouting, etc. in use. Agreed that we need to have a more precise and semantically appropriate terminology for tagging. Issue: Marking History-Info Entries An extended discussion developed on what H-I is used for, what the scope of our chartered work here is, and so on. It was noted that our scope here is to address the requirement to deliver the initial request-URI target to the UAS, which is required in 800-number translation (free-dial) services. (editors note: This is only true is the PSTN model is maintained; when not doing PSTN interworking, there are many other ways to approach such alias operations, including per- alias GRUU minting.) Issue: Progress 4244bis, target-uri draft, or both? In the absence of a clear consensus, the chairs proposed that both documents proceed and we'll hope that further discussion gives us a consensus. Topic: Info EventsLed by: Eric Burger draft-ietf-sip-info-events-03 Slides presented and included in minutes Issue: 489 Noted that while we agree that the content of the INFO itself does not directly change the state of the SIP machine, that protocol operations at the SIP level (such as cseq numbers and failure conditions) certainly do change the SIP state machine's state. Issue: Where to allow/disallow Recv-info processing? We agree that processing Recv-Info in 100 messages doesn't make a lot of sense. We do not seem to have a use case for Recv-Info in PRACK/ PRACK-2xx or REFER, but currently see no real reason to forbid its use there. Chair polled room for WGLC-readiness, and it seems that most people believe the draft is essentially ready. Session 2, DISPATCH-like topicsTopic: SIP VIa CookiesLed by: Theo Zourzouvillys draft-zourzouvillys-sip-via-cookie-02 Slides presented and included in minutes Discussion showed a strong interest in the work, and a general consensus that switching to TCP is not an acceptable solution to the problems raised. Further discussion on approach and attack- prioritization is to be deferred to the list. Topic: Keepalive Without OutboundLed by: Christer Holmberg draft-holmberg-sip-keep-03 Slides presented and included in minutes Presentation focused on use cases and requirements. It is not clear from the presentation whether there have been requirements changes since the preceding version. The author expects to submit a revised draft that will address all the use cases, so further discussion os deferred to the list after posting of the revised draft. Topic: Secure Call IDLed by: Hadriel Kaplan draft-kaplan-sip-secure-call-id-00 Slides presented and included in minutes A great deal of discussion ensued, with very little in the way of recognizable notes, or for that matter, recognizable progress, being made. Having a recognizer in the call identifier It was proposed that the "new safe identifier" have some sort of recognizer token, so that SBCs could easily decide not to change it. This proposal was rejected, on the grounds that some UAs today send "safe" call-ids that do not need to be changed, but that do not contain the proposed recognizer token. Issue: Changing the ABNF Noted that changing the ABNF is not nadvisable, as this might cause some picky nodes to reject legacy messages. This guidance may be better constructed as a "best practice." Further discussion deferred to list. Topic: Session IDLed by: Hadriel Kaplan draft-kaplan-sip-session-id-01 Slides presented and included in minutes Extended discussion focused on the use case and relationship to Call- ID. Further discussion centered on whether SBCs can be presumed to leave anything lone -- after all, many strip unknown headers already. Further discussion was deferred to the list. Topic: User to User for ISDNLed by: Alan Johnston draft-johnston-sipping-cc-uui-07 Slides presented and included in minutes Issue: Do we need INFO-style meta-information Alan argues that no negotiation on data types is needed if this is requested to only ISDN-style user-to-user data. However, many participants seemed to believe that if the header is there, somebody will use it for something new, and we'll be back to where we were with non-negotiated INFO usages and having to guess about whether the other party understands the payload. Issue: Header vs. body? Proposed mechanism is to put the data in a SIP header, whereas our traditional approach to these sorts of things is to use a MIME body. There seemed to be a lack of consensus about this approach in the room. Topic: Batch NOTIFYsLed by: Alan Johnston draft-johnston-sipping-batch-notify-00 Slides presented and included in minutes The room seems to have a consensus that more discussion at the requirements level is needed before we get into mechanism. Topic: Context-ID RequirementsLed by: Salvatore Loreto draft-loreto-sipping-context-id-requirements Slides presented and included in minutes Noted that this may be the tip of the iceberg for a larger body of disaggregated media work that we may need to address, and this raises many interesting questions. Further discussion is needed on-list. Topic: Changes to Referred-ByLed by: Salvatore Loreto draft-loreto-sipping-3892bis-01 Slides presented and included in minutes Issue: Including multiple P-Asserted-Identity values in Referred-By Noted that we need to understand what a receiver does with multiple identity expressions. Also noted that if multiple identities make sense for P-Asserted-Identity, they may make sense for Referred-By. No conclusion noted. Topic: Updates to the Updates to Asserted Identity in SIPLed by: Hadriel Kaplan draft-kaplan-sipping-pai-responses-00 Slides presented and included in minutes Noted by chair Dean That the current model "no identity in responses" was driven by security review on the initial work, and that changing to allow use in responses requires overcoming the objections raised at that time, which primarily relate to authentication of responses. Discussion revealed that there may be use cases, specifically around draft-ietf-sip-outbound, where separate authentication of responses may not be required, and that this mechanism was not available at the time RFC 3325 was developed. Further discussion was deferred to the list. Topic: Digest Relay AttackLed by: Raphael Coeffic draft-state-sip-relay-attack-00 Slides presented and included in minutes Initial discussion focused on the threat model in the draft and how this relates to message authentication. Authors noted that Section 4 is weak and they may wish to remove it. Chair noted that the question should be "Are these attacks important enough to describe them in BCP, and determine if we have interest in addressing them." Meeting concluded From drage@alcatel-lucent.com Wed Apr 15 06:24:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DC13A6E49 for ; Wed, 15 Apr 2009 06:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.063 X-Spam-Level: X-Spam-Status: No, score=-4.063 tagged_above=-999 required=5 tests=[AWL=-1.814, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObNzHFWdK2Em for ; Wed, 15 Apr 2009 06:24:15 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 660DB3A6C1C for ; Wed, 15 Apr 2009 06:24:15 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3FDPPO2011087 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 15 Apr 2009 15:25:25 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 15 Apr 2009 15:25:26 +0200 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" Date: Wed, 15 Apr 2009 15:25:23 +0200 Thread-Topic: Future of this mailing list Thread-Index: Acm9zaHI39/zqgJ8TyuYMcInmZfROQ== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D675884B51@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: [Sip] Future of this mailing list X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 13:24:16 -0000 If you are currently using this mailing list for discussion of documents ot= her than those listed below: - you should consider subscribing to one, other or both of the sipcore or d= ispatch mailing lists. https://www.ietf.org/mailman/listinfo/dispatch https://www.ietf.org/mailman/listinfo/sipcore - you should think about starting new threads, and transferring existing th= reads to these mailing lists (see the charters to work out which one). Obvi= ously as everyone needs to resubscribe, you should probably leave this a we= ek or so until that has occurred. My understanding of the documents that should continue to be discussed on t= his list (because they are all with the IESG or beyond) are: - draft-ietf-sip-gruu (in RFC editor's queue) - draft-ietf-sip-ice-option-tag (in RFC editor's queue) - draft-ietf-sip-sips (in RFC editor's queue) - draft-ietf-sip-dtls-srtp-framework (in RFC editor's queue) - draft-ietf-sip-outbound - draft-ietf-sip-certs - draft-ietf-sip-session-policy-framework - draft-ietf-sip-record-route-fix - draft-ietf-sip-body-handling - draft-ietf-sip-connect-reuse - draft-ietf-sip-domain-certs - draft-ietf-sip-eku - draft-ietf-sip-ua-privacy - draft-ietf-sip-xcapevent - draft-ietf-sip-location-conveyance (until potential transfer to GEOPRIV o= r some other handling is discussed and resolved) I hope I have the above list correct. If you think there are errors then pl= ease inform me. General discussion of sip issues should not occur on this list. And finally, I suggest that crossposting to multiple lists (old or new) sho= uld be avoided. regards Keith= From dean.willis@softarmor.com Wed Apr 15 15:23:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1FB3A6AC3 for ; Wed, 15 Apr 2009 15:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 QWW-w8fSJsox for ; Wed, 15 Apr 2009 15:23:13 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 06E503A69E8 for ; Wed, 15 Apr 2009 15:23:12 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3FMONEn026959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 15 Apr 2009 17:24:25 -0500 Message-Id: <7031B6D0-2438-4A8E-8C12-8F307288B0F8@softarmor.com> From: Dean Willis To: "sip@ietf.org List" Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 17:24:18 -0500 X-Mailer: Apple Mail (2.930.3) Subject: [Sip] Linked minutes, slides, and audio recordings for SIP at IETF 74 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 22:23:14 -0000 Check out: http://www.softarmor.com/mediawiki/index.php/SIP_Audio_for_IETF_74 I'd like to thank Vijay Gurbani for putting this all together. -- Dean, coChairless (is that like "The Stand" by Stephen King?) From christer.holmberg@ericsson.com Thu Apr 16 01:33:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989723A6AB1; Thu, 16 Apr 2009 01:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.796 X-Spam-Level: X-Spam-Status: No, score=-5.796 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoUW4VoFEf6Q; Thu, 16 Apr 2009 01:33:09 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 26B333A68B3; Thu, 16 Apr 2009 01:33:09 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E10F92109C; Thu, 16 Apr 2009 10:34:20 +0200 (CEST) X-AuditID: c1b4fb3c-adfd1bb00000238f-00-49e6ed8cc090 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BF55C21074; Thu, 16 Apr 2009 10:34:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 10:33:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BE6D.C021EDFF" Date: Thu, 16 Apr 2009 10:31:34 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new version: draft-holmberg-sipcore-keep-00 (previously known as draft-holmberg-sip-keep) Thread-Index: Acm+bcAszQkyqV++Ts+HPG29TfGFgA== From: "Christer Holmberg" To: , X-OriginalArrivalTime: 16 Apr 2009 08:33:26.0227 (UTC) FILETIME=[02F83230:01C9BE6E] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo , Mary Barnes Subject: [Sip] Draft new version: draft-holmberg-sipcore-keep-00 (previously known as draft-holmberg-sip-keep) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 08:33:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BE6D.C021EDFF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a draft-holmberg-sipcore version of the keep draft. The draft is identical to the previous version (for which Mary sent out the ask-for-support e-mail), but I have added one more example. The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-keep-00.tx t Regards, Christer Ps. I applogize for sending this e-mail to both SIP and SIPCORE, but since everyone may not have subscribed to SIPCORE yet... ------_=_NextPart_001_01C9BE6D.C021EDFF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: draft-holmberg-sipcore-keep-00 (previously = known as draft-holmberg-sip-keep)

Hi,

I've submitted a draft-holmberg-sipcore = version of the keep draft.

The draft is identical to the previous = version (for which Mary sent out the ask-for-support e-mail), but I have = added one more example.

The draft can also be found at:

http://users.piuha.net/cholmber/drafts/draft-holmberg-sipc= ore-keep-00.txt


Regards,

Christer

Ps. I applogize for sending this e-mail = to both SIP and SIPCORE, but since everyone may not have subscribed to = SIPCORE yet...

------_=_NextPart_001_01C9BE6D.C021EDFF-- From john.elwell@siemens-enterprise.com Thu Apr 16 01:59:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD0D3A6B59 for ; Thu, 16 Apr 2009 01:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 NK8VoKjx77Yo for ; Thu, 16 Apr 2009 01:59:10 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 7B8623A6B1E for ; Thu, 16 Apr 2009 01:59:10 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KI60065TROLNU@siemenscomms.co.uk> for sip@ietf.org; Thu, 16 Apr 2009 10:00:21 +0100 (BST) Date: Thu, 16 Apr 2009 10:00:20 +0100 From: "Elwell, John" In-reply-to: <03f301c9bd59$76c6d150$c5f0200a@cisco.com> To: Dan Wing , Jon Peterson , Francois Audet , Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001C1F8D8@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field thread-index: Acm3PPXKP9w6zOP0Qkau1hzJ1G25fABe3MZVAAnBxjAAGSCkQAAAfJAwACw2o5sABO07UAACAyOlAJLdPdAAAaBeFgAAfZ3wAAGstvYABvrh8AAzKBrIAADvo+AARbMeoA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <03f301c9bd59$76c6d150$c5f0200a@cisco.com> Cc: Cullen Jennings , sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 08:59:11 -0000 X could be equal to Y. In each case, the SDP body is excluded. In the one case the SDP body doesn't exist, in the other it exists but is not signed. John > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: 15 April 2009 00:34 > To: 'Jon Peterson'; 'Francois Audet'; Elwell, John; 'Dean Willis' > Cc: 'Cullen Jennings'; sip@ietf.org; 'DRAGE,Keith (Keith)' > Subject: RE: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Jon Peterson [mailto:jon.peterson@neustar.biz]=20 > > Sent: Tuesday, April 14, 2009 4:07 PM > > To: Dan Wing; 'Francois Audet'; 'Elwell, John'; Dean Willis > > Cc: Cullen Jennings; sip@ietf.org; 'DRAGE,Keith (Keith)' > > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > > used in the field > >=20 > >=20 > > On 4/13/09 3:45 PM, "Dan Wing" wrote: > >=20 > > >> I have a hard time seeing how anything we > > >> do at the media layer is salient to that - again, just=20 > > speaking to high > > >> level examples, if you accept a forged BYE request, > > >=20 > > > The BYE would be protected from forgery sufficient to detect a > > > forgery, using mechanisms like RFC4474 protects a BYE from > > > forgery: signing enough SIP headers to block a forgery. > >=20 > > In so far as there's really any thrust to my argument here,=20 > > it's that the > > situation of an INVITE that an attacker never intends to use=20 > > to establish a > > session is comparable to that of a BYE - one must sign enough=20 > > of its headers > > to detect a forgery to thwart its mischief. The problem is,=20 > > of course, that > > there's no way for the security mechanism to differentiate=20 > > these sorts of > > INVITEs from the "sunny day" session-establishment cases=20 > > where media-layer > > security will eventually be invoked, which makes me question=20 > > exactly how > > much we can reduce the set of INVITE headers we sign. > >=20 > > This doesn't mean I object fundamentally to a two-pronged=20 > > solution; say, > > signing set X of fields for all requests with an SDP body and=20 > > set Y for all > > requests without an SDP body. It just means that in the=20 > > threat model I'm > > considering, I have reservations about making X much smaller than Y. >=20 > Yes, I agree we need to sign enough headers to prevent an attack. >=20 > -d >=20 >=20 > > Jon Peterson > > NeuStar, Inc. > >=20 > > >> that will presumably > > >> convince you to tear down a call regardless of anything=20 > > that media-layer > > >> security has established. I've argued a similar=20 > > requirement exists to > > >> prevent a forged re-INVITE that just sets the IP/port to > > >> something useless. > >=20 >=20 >=20 From john.elwell@siemens-enterprise.com Thu Apr 16 01:59:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529FC28C0CE for ; Thu, 16 Apr 2009 01:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 NpX2A44Pi+xj for ; Thu, 16 Apr 2009 01:59:20 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 3A1D73A6BC7 for ; Thu, 16 Apr 2009 01:59:20 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KI60066SROVNU@siemenscomms.co.uk> for sip@ietf.org; Thu, 16 Apr 2009 10:00:32 +0100 (BST) Date: Thu, 16 Apr 2009 10:00:30 +0100 From: "Elwell, John" In-reply-to: <49E5153B.8020501@nostrum.com> To: Adam Roach , Dan Wing Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001C1F8D9@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field thread-index: Acm9VMDMSKRpc/KxQeyAWruh1VOYiQBG8r+Q Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <00f001c9bc66$f9f63c80$c5f0200a@cisco.com> <021601c9bc89$865e7ad0$c5f0200a@cisco.com> <49E3DDD4.1040903@nostrum.com> <006101c9bcc4$44e1cb30$c5f0200a@cisco.com> <019a01c9bd19$13ac97c0$c5f0200a@cisco.com> <49E5153B.8020501@nostrum.com> Cc: Cullen Jennings , Jon Peterson , sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 08:59:21 -0000 Adam, =20 Yes, I think #2 might be the way ahead. We need to ensure that any changes of behaviour that we require from B2BUAs in intermediate domains is reasonable, in the sense that intermediate domains are not prevented from doing things they have reasonable grounds for needing to do, and that the burden on intermediate domains is not excessive (given that the intermediate domain is not the main beneficiary from e2e identity). For example, if we believe there is no fundamental reason for intermediate domains to modify the call-id value, we might require those that do modify call-id to change their behaviour. However, requiring intermediate domains to add a signature may or may not be considered too demanding. John ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Adam Roach Sent: 14 April 2009 23:59 To: Dan Wing Cc: 'Cullen Jennings'; 'Jon Peterson'; sip@ietf.org; 'Francois Audet'; 'DRAGE,Keith (Keith)'; 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field =09 =09 [with my individual contributor hat on] =09 Dan Wing wrote:=20 On SIP networks today we have intermediaries modifying SDP in transit. It's happening now, on real networks. I am really interested in preserving identity over those networks. =20 And I have HTTP proxies that I'd love to send RTP through. At some point, we've got to realize that certain types of old dogs aren't even remotely suited for particularly demanding new tricks -- at least, not without software upgrades. =09 I think it's important to distinguish among three classes of solutions in this space: =09 =09 1. Identity that works through existing B2BUAs=20 2. Identity that might not work through existing B2BUAs, but that B2BUAs can be modified to work with=20 3. Identity that precludes the presence of B2BUAs=20 There are clearly approaches that fit into each of these three categories. There are a number of people (and I count myself among them) who find the security properties of the proposals that fit into #1 to be odious. There are also people who clearly find proposals in class #3 unacceptable for their lack of pragmatism. =09 Now, there are also a number of people who have historically staked out extremist positions that state that only solutions in category #1 (or only solutions in category #3) are acceptable, and that neither of the other two options could possibly be acceptable. I think we need to ignore people arguing from either of these extreme positions, because their positions are mutually exclusive, and can never be rectified with each other. =09 At the risk of suggesting compromise, I'll point out that there *is* a way to mutually satisfy those people who reject solutions in class #1 and those people who reject solutions in class #3. I suspect that useful progress lies in that direction only. =09 /a =09 From adam@nostrum.com Thu Apr 16 11:38:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34EAA3A6B0F for ; Thu, 16 Apr 2009 11:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, SPF_PASS=-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 5kRybv6o4lky for ; Thu, 16 Apr 2009 11:38:34 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 2BD4A3A6ABF for ; Thu, 16 Apr 2009 11:38:33 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3GIdjK0007379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Apr 2009 13:39:45 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E77B71.5020608@nostrum.com> Date: Thu, 16 Apr 2009 13:39:45 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041423) MIME-Version: 1.0 To: SIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 18:38:35 -0000 This message is for those of you who haven't subscribed to SIPCORE yet. We're doing the heavy lifting of spinning stuff up right now, and you'll probably want to pay attention (both so you understand what's going on, and also to make sure the new chairs don't flub something up in the transition). Because they are of particular import, I'm going to point out the following two messages on the SIP list: http://www.ietf.org/mail-archive/web/sipcore/current/msg00004.html ...and... http://www.ietf.org/mail-archive/web/sipcore/current/msg00005.html If you didn't get your own copy of these messages, please double-check that you're subscribed to the SIPCORE mailing list: https://www.ietf.org/mailman/listinfo/sipcore /a From rjsparks@nostrum.com Fri Apr 24 11:47:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645D03A6966; Fri, 24 Apr 2009 11:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 PLcXO2UxfgMp; Fri, 24 Apr 2009 11:47:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C5EA73A6CFA; Fri, 24 Apr 2009 11:47:57 -0700 (PDT) Received: from [192.168.2.2] (pool-173-57-111-84.dllstx.fios.verizon.net [173.57.111.84]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3OInE0K099874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Apr 2009 13:49:14 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: SIP IETF , sipcore@ietf.org, rai@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-203-298749059 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 24 Apr 2009 13:49:13 -0500 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 173.57.111.84 is authenticated by a trusted mechanism) Subject: [Sip] Registration for SIPit 24 closes next week X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:47:59 -0000 --Apple-Mail-203-298749059 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Registration for SIPit 24 closes April 30. If you are not yet registered, but plan to attend, please register now. SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan hosted by JPNIC and NICT. Additional information is available at http://www.sipit.net and http://www.nic.ad.jp/en/sipit24/ --Apple-Mail-203-298749059 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Registration for SIPit 24 closes April 30. If you are not yet registered, but plan to attend, please register now.

SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan  
hosted by JPNIC and NICT.
Additional information is available at http://www.sipit.net and http://www.nic.ad.jp/en/sipit24/
--Apple-Mail-203-298749059-- From wwwrun@core3.amsl.com Mon Apr 27 15:55:49 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 659993A6F63; Mon, 27 Apr 2009 15:55:48 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090427225549.659993A6F63@core3.amsl.com> Date: Mon, 27 Apr 2009 15:55:49 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] Last Call: draft-ietf-sip-ua-privacy (UA-Driven Privacy Mechanism for SIP) to Informational RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 22:55:49 -0000 The IESG has received a request from the Session Initiation Protocol WG (sip) to consider the following document: - 'UA-Driven Privacy Mechanism for SIP ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-05-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16751&rfc_flag=0