From sip-bounces@ietf.org Tue Aug 01 01:16:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7maF-0004Y9-Ik; Tue, 01 Aug 2006 01:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7maE-0004UN-1t; Tue, 01 Aug 2006 01:14:22 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7maC-0001fV-Oh; Tue, 01 Aug 2006 01:14:22 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 00:14:18 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 01 Aug 2006 00:14:18 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 00:14:17 -0500 Message-ID: From: "Dawson, Martin" To: "Andrew Newton" , "Winterbottom, James" Date: Tue, 1 Aug 2006 00:14:15 -0500 Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTPdereferencemechanism defined MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 01 Aug 2006 05:14:17.0564 (UTC) FILETIME=[567829C0:01C6B529] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <80BD9605-F287-487E-AF4A-5697A50AB8E4@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTPdereferencemechanism defined Thread-Index: Aca1B+ZeLLsjYFmHQQ2U8yRlbuTwXgAIJqCA X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: IETF SIP List , "Rosen, Brian" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm OK as long as the ABNF includes the AbsoluteURI option and the text does not say anything specifically about excluding HTTP (or any other form of URI). I've attempted to point out previously that the URI doesn't actually convey anything about whether the geopriv rules are going to be respected or not. It's actually a geopriv rule that those rules be respected so it's superfluous, and out of scope, to also require the statement in a SIP conveyance document. AbsoluteURI as a generic form, encompasses sip etc. anyway, so it's also superfluous to include those in the ABNF. However, it's also a harmless waste of space. If Brian is keen to include them for some reason, and as long as neither the text nor the ABNF bias the specification toward those forms in any way, then there are certainly better things to lose sleep over. Cheers, Martin > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, 1 August 2006 11:15 AM > To: Winterbottom, James > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an > HTTPdereferencemechanism defined >=20 >=20 > On Jul 31, 2006, at 9:11 PM, Winterbottom, James wrote: >=20 > > Hi Andy, > > > > That is all I have asked for, do not constrain the ABNF. If "how I > > use HTTP as a reference" goes in a different document that is fine > > providing the ABNF is not constrained in the conveyance > > specification. This is not how I read Brian's statement below: > > > > "This is NOT the discussion of what the ABNF of the location header > > looks > > like (although it would NOT have http/https in it for sure if we agree > > that an HTTP dereference protocol is a separate draft)." > > > > Which to me clearly says the ABNF will be restrict to exclude HTTP/ > > HTTPS if there is agreement that the conveyance draft doesn't have > > specific text on how to deference an HTTP reference. > > > > Cheers > > James >=20 > Please keep in mind that this does not stop the draft from using MUST/ > SHOULD language from stipulating "the URI MUST be a GEOPRIV standards > track using protocol." >=20 > -andy >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 01 01:27:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7mks-0000ll-O7; Tue, 01 Aug 2006 01:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7mkr-0000lg-9D for sip@ietf.org; Tue, 01 Aug 2006 01:25:21 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7mko-0002UI-QI for sip@ietf.org; Tue, 01 Aug 2006 01:25:21 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 1 Aug 2006 07:25:17 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Aug 2006 07:25:17 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A6AE@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: jdrosen@cisco.com, sip@ietf.org Subject: AW: [Sip] updated acr code draft Date: Tue, 1 Aug 2006 07:25:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In this Draft is described that: The request contained a Privacy header field whose value was 'id' [3] or 'user'. This explicitly excludes the 'header' and 'session' privacy services, since those do not directly convey = the identity of the requestor. Why the value 'header ' is exluded?=20 In RFC3323 is described that header: header: The user requests that a privacy service obscure those headers which cannot be completely expunged of identifying information without the assistance of intermediaries (such as Via and Contact). Also, no unnecessary headers should be added by = the service that might reveal personal information about the originator of the request. So from my understanding 'id' is a subset of 'header' because the = P-Asserted-Identity can only be deleted by untermediarities. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Gesendet: Montag, 31. Juli 2006 22:31 An: IETF SIP List Betreff: [Sip] updated acr code draft I've submitted a minor update to the ACR code draft. Until it appears,=20 you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt the changes are: * replaced P-Asserted-ID with P-Asserted-Identity * added to security considerations section, consideration for anonymizers in the network. Namely, don't retry request on receipt of 433 unless explicitly configured to do so by user Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ = 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 01 02:01:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7nHo-0007fc-EM; Tue, 01 Aug 2006 01:59:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7nHl-0007Qu-HJ for sip@ietf.org; Tue, 01 Aug 2006 01:59:21 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7nHk-00067P-6q for sip@ietf.org; Tue, 01 Aug 2006 01:59:21 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 31 Jul 2006 22:59:20 -0700 X-IronPort-AV: i="4.07,200,1151910000"; d="scan'208"; a="309028672:sNHT27092406" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k715xJeO027414; Mon, 31 Jul 2006 22:59:19 -0700 Received: from [192.168.1.2] (sjc-vpn4-560.cisco.com [10.21.82.48]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k715xImQ016753; Mon, 31 Jul 2006 22:59:18 -0700 (PDT) In-Reply-To: <028f01c6a576$0afbdcc0$d30bdb84@acmepacket.com> References: <028f01c6a576$0afbdcc0$d30bdb84@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Mon, 31 Jul 2006 22:59:21 -0700 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2356; t=1154411959; x=1155275959; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20rosenberg-sip-identity-coexistence; X=v=3Dcisco.com=3B=20h=3D3W76qn12oY3/kO35fx2svo0v6Rs=3D; b=hjhCQ089l6O/gCjRpTz9GChQ2XoOFYAZbcKrrzxVbj5X6HOSNkyjMA0f65NrlcfOIaPEkA+U Cqy2mGwioKe1HCz7W6WM3EPdQnk6SZC3CvscQb6h0GrXuxwLP8r6kZ2s; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keep in mind a B2BUA always breaks end to end security because the B2BUA is the end. If C is only a proxy and does not have a b2bua, everything seems to work find between B and D. I think I am missing what the problem is here. I perfectly willing to believe there is a problem - I just think that I am not clear yet on the scenario you are thinking about. Cullen On Jul 11, 2006, at 10:42 PM, Hadriel Kaplan wrote: >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> >> Ok, I am done't think I am manging to explaim myself. Say A has a >> contract with B and B has a crontract with C. Now a call arrives at >> C, it seem that C wants a assertion to be made by B. Anything A says >> to C is clsoe to useless because C has no clue who A even is. I guese >> I feel like we need to sort out the requirements for what we want in >> a transit case and then we might be able to figure out a solution. > > One of the problems with the idea of a b2bua re-signing it is how > to trust > the b2bua. I.e., if the domain the b2bua is in is not the same as the > From's, then you have to somehow trust the different domain. I > agree with > you there's a common model of "I trust the domain connected to me > directly". > > > So if you have an A-B-C chain as you describe, then sure A can > sign, then B > can verify A and re-sign with B-cert, and C can verify B. Now imagine > A-B-C-D; A and B have a b2bua, but C doesn't. A signs, then B > verifies and > signs with B-cert, C does nothing and D gets a From of A with a > cert of B > and does what? > In other words, unless they all re-sign, it's limited to a small > chain. But > if they all re-sign, we're back to hop-by-hop trust. Well... fewer > hops > because it's domain-by-domain instead of proxy-by-proxy, so it is > better. > > But is domain by domain resigning acceptable? It breaks the end-to- > end > model of identity, so I would think not. And making every domain > re-sign > would have a serious flag-day problem. (not to mention quite an > impressive > performance/scale issue I suspect) At the same time, in your > example C does > not have a contract with A, so the business model is not end-to-end > - so I'm > not sure why the trust would be. > > -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 01 02:01:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7nII-0007xC-Kw; Tue, 01 Aug 2006 01:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7nIH-0007x7-7D for sip@ietf.org; Tue, 01 Aug 2006 01:59:53 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7nIF-0006AM-Qn for sip@ietf.org; Tue, 01 Aug 2006 01:59:53 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 31 Jul 2006 22:59:51 -0700 X-IronPort-AV: i="4.07,200,1151910000"; d="scan'208"; a="1843211316:sNHT28456740" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k715xovL027589; Mon, 31 Jul 2006 22:59:50 -0700 Received: from [192.168.1.2] (sjc-vpn4-560.cisco.com [10.21.82.48]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k715xImR016753; Mon, 31 Jul 2006 22:59:50 -0700 (PDT) In-Reply-To: <44C11AAC.2010705@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB594017F1266@esealmw113.eemea.ericsson.se> <44C11AAC.2010705@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [Sip] draft-ietf-sip-outbound and STUN keepalives Date: Mon, 31 Jul 2006 22:59:57 -0700 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=3681; t=1154411990; x=1155275990; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-outbound=20and=20STUN=20keepalives; X=v=3Dcisco.com=3B=20h=3DuArLC5t0+VP0VDY6TKeXuGKvp74=3D; b=MYwWCqEwzo2ZpV7ctdsGwvtbk/eCAZ+lLjuZwkDp0MhCtAeCPDGmh5CJAs++WmjC6x8K1ZYc qPswCFtLpZAyg8Klii6EplXy5nYDeSEw1DaEGulLKtUq+N3uKF5N7vM+; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sip@ietf.org, Rohan Mahy , "Drage, Keith \(Keith\)" , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yep - I think the intention was to do as Jonathan said. On Jul 21, 2006, at 11:19 AM, Jonathan Rosenberg wrote: > Right. I mentioned this in the behave meeting. The idea is that =20 > rfc3489bis formally defines the usage, and calls out additional =20 > things that an actual protocol that uses it, would have to say. =20 > Then sip-outbound says those things. > > -Jonathan R. > > Christer Holmberg (JO/LMF) wrote: > >> Hi Keith, >> I am ok with the proposal. >> In the "STUN keep-alive: Where to document it?" thread (http://=20 >> www1.ietf.org/mail-archive/web/sip/current/msg15227.html) it is =20 >> discussed where different things related to STUN keep-alive should =20= >> be documented. Some things MAY have to be documented in 3489bis. >> Regards, >> Christer >> -----Original Message----- >> From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: 20. =20 >> hein=E4kuuta 2006 15:11 >> To: 'sip@ietf.org' >> Subject: [Sip] draft-ietf-sip-outbound and STUN keepalives >> (As WG chair) >> Previous mails on the SIP list have expressed the view that the =20 >> STUN keepalive mechanism should be documented separately as it is =20 >> a useful mechanism in its own right. >> See http://www3.ietf.org/proceedings/06jul/slides/sip-5.pdf slide =20 >> 5 for the issue as raised at the IETF #66 meeting.=09 >> After discussion with the editor, the WG chairs propose the =20 >> following: >> - that the documentation on STUN keepalive will REMAIN in the =20 >> outbound document, and WILL NOT be split to a separate specification; >> - that the STUN keepalive mechanism WILL BE separated within the =20= >> outbound specification, such that it is clear that it can be =20 >> implemented independently of the rest of the outbound =20 >> specification, and so that the keepalive material is clearly =20 >> referencable in its own right. >> We believe that this meets the requirements of at least most of =20 >> the working group, and for pragmatic reasons we want to work =20 >> against more fragmentation of the SIP documentation. >> If you have problems with this proposal and desire a different =20 >> solution, then please raise your concerns to the list, or direct =20 >> to the WG chairs, in response to this mail. >> regards >> Keith >> Keith Drage >> drage@lucent.com >> tel: +44 1793 776249 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use sip-=20 >> implementors@cs.columbia.edu for questions on current sip Use =20 >> sipping@ietf.org for new developments on the application of sip >> _______________________________________________ >> Sip mailing list https://www1.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 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ =20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 01 02:02:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7nJL-0000Fc-39; Tue, 01 Aug 2006 02:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7nJJ-0000FS-8P for sip@ietf.org; Tue, 01 Aug 2006 02:00:57 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7nJH-0006MZ-W3 for sip@ietf.org; Tue, 01 Aug 2006 02:00:57 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 31 Jul 2006 23:00:41 -0700 X-IronPort-AV: i="4.07,200,1151910000"; d="scan'208"; a="309028893:sNHT40814792714" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7160bwP014079; Mon, 31 Jul 2006 23:00:37 -0700 Received: from [192.168.1.2] (sjc-vpn4-560.cisco.com [10.21.82.48]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k715xImS016753; Mon, 31 Jul 2006 23:00:37 -0700 (PDT) In-Reply-To: <06C96942-34A9-481A-86FF-F8B02CBFFC01@softarmor.com> References: <0306223F-C113-47A0-B148-5E0E5B7E2159@estacado.net> <06C96942-34A9-481A-86FF-F8B02CBFFC01@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <102DF855-2BA7-42D6-863C-C09110D0DD6F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Proposals for review process to conclude WGLCs Date: Mon, 31 Jul 2006 23:00:45 -0700 To: Dean Willis X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=437; t=1154412037; x=1155276037; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Proposals=20for=20review=20process=20to=20conclude=20WGL Cs; X=v=3Dcisco.com=3B=20h=3DHRBeb4NuiavNNp5JcrewXT7YLsk=3D; b=sBrqIdoMJah55Nkmwce4YEFU5HeeoxEN64+IMmgLzJkwhFPUsJgoyTcWSTq4tMMCMcZbZODt fve1yQstnD0blP5LRv89xJlMuT7U2NgO+7+mzFXUu219rXJU42LYPs7v; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 9, 2006, at 6:22 PM, Dean Willis wrote: > This can usually be sorted out for groups of 3-5 people selected > from a large pool, assuming they're willing to work between 7:00 AM > and midnight in their home time zones. Of course, that does leave > out at least one area director I know of . . . If you assume that Jon is based out of Pago Pago and that I am out of Anchorage, your algorithm still works fine. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 01 03:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7opS-0001s1-Uq; Tue, 01 Aug 2006 03:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7opR-0001rw-9l for sip@ietf.org; Tue, 01 Aug 2006 03:38:13 -0400 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7opP-0007wS-Rr for sip@ietf.org; Tue, 01 Aug 2006 03:38:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] updated GRUU spec Date: Tue, 1 Aug 2006 08:38:10 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23DF2@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] updated GRUU spec thread-index: Aca05L39hbQWA3O7RIGWCoXZJo2TowAWVv2w From: "Attila Sipos" To: "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org For those who didn't see a link, it's at: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-10.txt Cheers, Attila Attila Sipos http://www.vegastream.com >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 31 July 2006 22:03 >> To: IETF SIP List >> Subject: [Sip] updated GRUU spec >>=20 >>=20 >> I've just submitted an update to the GRUU spec based on=20 >> comments on the=20 >> list. Until it appears, you can pick it up at: >>=20 >> * noted that, in the outbound direction, if the home proxy is not on >> the original request path, another proxy in that domain=20 >> needs to put in=20 >> a record-route >> that points to it. Provide links to some mechanism which=20 >> allows a home >> proxy to get on the outbound request path >>=20 >> * clarified that, if an outbound proxy is used, the request has to >> visit the domain from which the gruu was obtained before being >> forwarded to the party in the r-uri. There are two ways documented >> to know this: >>=20 >> a. using a service route obtained from the same proxy=20 >> that sent you >> a gruu >>=20 >> b. using an outbound proxy; configuration tells you what=20 >> domain its >> from >>=20 >>=20 >> * noted that an outbound proxy is not needed; rules above only apply >> when one is used >>=20 >> * clarified the interaction of caller prefs and callee caps with gruu >>=20 >> * clarified how a proxy determines that a request is a mid-dialog >> request >>=20 >> * clarified that GRUU basically implies you can't have a sip dialog >> without registration >>=20 >> * clarified that a UA, in processing a REGISTER response, is going to >> have to search for and extract its own contacts in case other UA >> registered against the same AOR >>=20 >> * changed rules on inclusion of grid/gruu URI param in the contact. A >> registered contact cannot have a grid or gruu URI >> param if its also got an instance ID. If there is no=20 >> instance ID its >> ok. Correspondingly, removed check on making sure a=20 >> contact wasn't a >> gruu for the AOR in the To field. This is not necessary=20 >> now, and in >> fact is permitted and works fine. >>=20 >> * clarified that proxy processing of 'initial' requests applies when >> there are no Route headers. Consequently, treatment of >> dialog-forming requests which happen to have route headers is not >> specified. >>=20 >> * removed rfc2119 strength text from requirements section >>=20 >>=20 >>=20 >> Thanks, >> Jonathan R. >> --=20 >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany,=20 >> NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >>=20 >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 01 10:46:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vU9-0005tv-QT; Tue, 01 Aug 2006 10:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vU7-0005no-NE for sip@ietf.org; Tue, 01 Aug 2006 10:44:39 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7vU6-0007zN-HM for sip@ietf.org; Tue, 01 Aug 2006 10:44:39 -0400 Received: from s73602 (futurewei.com?[65.104.224.98]) by comcast.net (sccrmhc14) with SMTP id <2006080114443501400bpjsie>; Tue, 1 Aug 2006 14:44:35 +0000 Message-ID: <117c01c6b578$d52ac210$0400a8c0@china.huawei.com> From: "Spencer Dawkins" To: "IETF SIP List" References: <5D1A7985295922448D5550C94DE2918013B758@DEEXC1U01.de.lucent.com> Subject: Re: [Sip] Hitchhikers guide - when is it done? Date: Tue, 1 Aug 2006 09:43:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Keith on both points. Spencer ----- Original Message ----- From: "Drage, Keith (Keith)" To: "Jonathan Rosenberg" ; "IETF SIP List" Sent: Tuesday, July 25, 2006 1:07 PM Subject: RE: [Sip] Hitchhikers guide - when is it done? (As individual) I also prefer option 2. I think the IETF has to solve the problem of more rapid revision of documents. Regards Keith _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 01 14:55:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zNH-0003FE-Fa; Tue, 01 Aug 2006 14:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zNG-0003EI-AH; Tue, 01 Aug 2006 14:53:50 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7zND-0002Lh-Uf; Tue, 01 Aug 2006 14:53:50 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k71IrhfH025849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2006 11:53:44 -0700 Received: from [10.0.1.4] (vpn-10-50-16-157.qualcomm.com [10.50.16.157]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k71Ire8S020369; Tue, 1 Aug 2006 11:53:42 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4DA40460-5855-4BC2-8605-48F9F8EC7BAC@hxr.us> References: <4DA40460-5855-4BC2-8605-48F9F8EC7BAC@hxr.us> Date: Tue, 1 Aug 2006 11:53:39 -0700 To: Andrew Newton , "Winterbottom, James" From: Ted Hardie Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF SIP List , "Rosen, Brian" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 9:03 PM -0400 7/31/06, Andrew Newton wrote: > >Brian is right. They are not the same issue, atleast they do not have to be. > >From where I sit, I think the consensus is: > - do not constrain the ABNF > - HTTP goes in another document > >Keep in mind, my hat is labeled "GEOPRIV" and this is a SIP document. I agree with the "HTTP goes in another document" statement of consensus (and the consensus appears to be that HTTP MUST be a using protocol). I think "do not constrain the ABNF" is not the right formulation though; I think the consensus is: "limit URI schemes to those approved here or in subsequent documents for this use". There are a variety of ways to make the ABNF say the latter, but the key difference is that it will always be a constrained list, but the list will grow over time. I would not be happy with a unconstrained ABNF, as there are lots of URI schemes that would not make sense here (tag? info? opaquelocktocken? mid? modem?). I am wearing no hats here. Ted _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 01 15:52:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80Fo-0007N0-Tv; Tue, 01 Aug 2006 15:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80Fe-000765-3a; Tue, 01 Aug 2006 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G80Fd-0008Rs-M3; Tue, 01 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id A17FF32873; Tue, 1 Aug 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G80Fd-0004z4-HL; Tue, 01 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 01 Aug 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-acr-code-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-acr-code-02.txt Pages : 8 Date : 2006-8-1 The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-acr-code-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-acr-code-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-1142134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-acr-code-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-acr-code-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-1142134.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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-- From sip-bounces@ietf.org Tue Aug 01 16:15:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80cJ-0000Dw-9S; Tue, 01 Aug 2006 16:13:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80cH-0000CW-MP for sip@ietf.org; Tue, 01 Aug 2006 16:13:25 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7zMh-000233-8Q for sip@ietf.org; Tue, 01 Aug 2006 14:53:15 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7z7g-00037w-St for sip@ietf.org; Tue, 01 Aug 2006 14:37:47 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 01 Aug 2006 11:37:40 -0700 X-IronPort-AV: i="4.07,203,1151910000"; d="scan'208"; a="1843405094:sNHT3000048262" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k71IbdiZ028290; Tue, 1 Aug 2006 11:37:39 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k71IbcBc006945; Tue, 1 Aug 2006 11:37:39 -0700 (PDT) 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); Tue, 1 Aug 2006 14:37:38 -0400 Received: from [161.44.55.123] ([161.44.55.123]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 14:37:38 -0400 Message-ID: <44CF9F72.4000109@cisco.com> Date: Tue, 01 Aug 2006 14:37:38 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Attila Sipos Subject: Re: [Sip] updated GRUU spec References: <8F1F2062CA7D754A838F0E66097D23A0C23DF2@veg-brk-svr-pri.vegastream> In-Reply-To: <8F1F2062CA7D754A838F0E66097D23A0C23DF2@veg-brk-svr-pri.vegastream> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2006 18:37:38.0272 (UTC) FILETIME=[90548600:01C6B599] DKIM-Signature: a=rsa-sha1; q=dns; l=3402; t=1154457459; x=1155321459; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20updated=20GRUU=20spec; X=v=3Dcisco.com=3B=20h=3DCUdLAyjyiWnemXjhyFeXb4tsT1o=3D; b=bjK4hhEXKfHb0w1RrSsZWJXNAKAremdZfk/DHdWUFEgDXcTEAtB3ImzQccIDPbHGKqW9zpaQ ictTEtTmqKrmZHsqnjVVYG/HTyD2pX3prZjze25YPIDmopajJKMuSQOK; Authentication-Results: sj-dkim-8.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Oops, my bad. Thanks for correcting Attila. -Jonathan R. Attila Sipos wrote: > For those who didn't see a link, it's at: > http://www.jdrosen.net/papers/draft-ietf-sip-gruu-10.txt > > Cheers, > Attila > > Attila Sipos > http://www.vegastream.com > > > >>>-----Original Message----- >>>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>>Sent: 31 July 2006 22:03 >>>To: IETF SIP List >>>Subject: [Sip] updated GRUU spec >>> >>> >>>I've just submitted an update to the GRUU spec based on >>>comments on the >>>list. Until it appears, you can pick it up at: >>> >>>* noted that, in the outbound direction, if the home proxy is not on >>>the original request path, another proxy in that domain >>>needs to put in >>>a record-route >>>that points to it. Provide links to some mechanism which >>>allows a home >>>proxy to get on the outbound request path >>> >>>* clarified that, if an outbound proxy is used, the request has to >>> visit the domain from which the gruu was obtained before being >>> forwarded to the party in the r-uri. There are two ways documented >>> to know this: >>> >>> a. using a service route obtained from the same proxy >>>that sent you >>> a gruu >>> >>> b. using an outbound proxy; configuration tells you what >>>domain its >>> from >>> >>> >>>* noted that an outbound proxy is not needed; rules above only apply >>>when one is used >>> >>>* clarified the interaction of caller prefs and callee caps with gruu >>> >>>* clarified how a proxy determines that a request is a mid-dialog >>>request >>> >>>* clarified that GRUU basically implies you can't have a sip dialog >>> without registration >>> >>>* clarified that a UA, in processing a REGISTER response, is going to >>> have to search for and extract its own contacts in case other UA >>> registered against the same AOR >>> >>>* changed rules on inclusion of grid/gruu URI param in the contact. A >>> registered contact cannot have a grid or gruu URI >>> param if its also got an instance ID. If there is no >>>instance ID its >>> ok. Correspondingly, removed check on making sure a >>>contact wasn't a >>> gruu for the AOR in the To field. This is not necessary >>>now, and in >>> fact is permitted and works fine. >>> >>>* clarified that proxy processing of 'initial' requests applies when >>> there are no Route headers. Consequently, treatment of >>> dialog-forming requests which happen to have route headers is not >>> specified. >>> >>>* removed rfc2119 strength text from requirements section >>> >>> >>> >>>Thanks, >>>Jonathan R. >>>-- >>>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>Cisco Fellow Parsippany, >>>NJ 07054-2711 >>>Cisco Systems >>>jdrosen@cisco.com FAX: (973) 952-5050 >>>http://www.jdrosen.net PHONE: (973) 952-5000 >>>http://www.cisco.com >>> >>>_______________________________________________ >>>Sip mailing list https://www1.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 >>> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 01 16:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8171-0003XQ-Js; Tue, 01 Aug 2006 16:45:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8171-0003VK-0F for sip@ietf.org; Tue, 01 Aug 2006 16:45:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G816z-00054h-Lr for sip@ietf.org; Tue, 01 Aug 2006 16:45:10 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-2.cisco.com with ESMTP; 01 Aug 2006 13:44:58 -0700 X-IronPort-AV: i="4.07,203,1151910000"; d="scan'208"; a="333202753:sNHT31484900312" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k71Kiv6B029159; Tue, 1 Aug 2006 13:44:57 -0700 Received: from [192.168.1.2] (sjc-vpn-hwcore-29.cisco.com [10.21.152.29]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k71KivBc005878; Tue, 1 Aug 2006 13:44:57 -0700 (PDT) In-Reply-To: <44AF59A8.1000304@lucent.com> References: <44ADE168.7050309@cisco.com> <44AF59A8.1000304@lucent.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <77482B40-90DF-43A7-BC76-07EA1AF05C52@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] comments on draft-ietf-sip-connect-reuse-05 Date: Tue, 1 Aug 2006 13:44:59 -0700 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=3258; t=1154465097; x=1155329097; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-connect-reuse-05; X=v=3Dcisco.com=3B=20h=3DGR+QyU0oZVkbvnn5V1JEI8Vyl0w=3D; b=maME/6RoxAJj6NhYxI7Ld9ZNSthTA2LcZSR0PgtwpL93M/u53tj9FlMoVe4bWhii3Ekyp3Y9 HXO+//98tOkKwoOkJLuNxEirtp7i1D1oXOiQkEuM7DG14BBokfzlgh3a; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Big question ... If the proxies always did this regardless of if there was an alias tag in the via or not, would everything work? I could not find something that did not work but I could easily be missing the obvious. I do note that alias indicates you want a long lived connection but everyone always wants to be long lived so we could just assume that. I don't think this works from some TLS situations. If a proxy is hosting two virtual domain red and blue both with TLS and use the same port for both using the extended hellos TLS options. Now both the red and blue domains have a user called tel:1234 but we don't want red tel:1234 to get IMs meant for blue. Blue sends an IM to Alice at some other domain. This forms an alias to the server. Now Red bob sends an IM to Alice - this updates the alias and basically hijacks blue. When ALice relies to blue, the proxy in Alice's domain will mistakenly select the TLS connection that was formed by red domain since it goes to the correct ip address, port, and transport. The virtual domain that servers red and blue will process the request in the context of red since it received it over a TLS connection that is part of the red domain. You might say this is a corner case but hosting multiple virtual domains this way is very desirable and the HTTP people have been working hard to make this easier to deploy. The latest version of common TLS libraries are starting to support this and I expect to see more servers that can do this. (PS. I think I have mentioned this on several different versions of this document - let me know if I am not making any sense) Seems like we should be more blunt up front that this does not work for TCP and can only be used for TLS Few trivial things ... Section 6 point 2 - since this is proxy to proxy, not sure this is relevant point 3 - seems like the if an ephemeral port is used, the mechanism will never share it so I don't think this requirement is satisfied. On the other hand, I don't think it matters that is is not satisfied. Section 8 para 2 - you use "default port if it does not" - I don't think this is right - it needs to be the port it was received from or you have a hijack issue. Section 9.1 - not sure this is exactly right but it seems like this is all a 3261 issue not really a connection reuse issue Section 9.2 introduces the term "canonical host name of the server" without defining it but I think this is sort of wrong. The thing that is in the cert needs to match whatever was put in the VIA. No more, no less. For some deployments, this will be a DNS names that refers to that specific server, for others it might refer to many servers. Section 9.2 is pretty wimpy about saying don't do this with TCP. How about something with some normative language like "This mechanism MUST NOT be used for TCP connections because there is no way to perform the authentication step" You say to send a 403 if the client can not provide a certificate, but what if it provides one but it is not signed by something in the root list of the server or is invalid in some other way (such as expired). _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 01 17:35:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81rw-0003qV-8s; Tue, 01 Aug 2006 17:33:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81ru-0003qK-S5 for sip@ietf.org; Tue, 01 Aug 2006 17:33:38 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G81rt-00030x-H7 for sip@ietf.org; Tue, 01 Aug 2006 17:33:38 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 01 Aug 2006 14:33:37 -0700 X-IronPort-AV: i="4.07,203,1151910000"; d="scan'208"; a="1843464232:sNHT27140260" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k71LXbU0020024; Tue, 1 Aug 2006 14:33:37 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k71LXaBc023419; Tue, 1 Aug 2006 14:33:36 -0700 (PDT) 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); Tue, 1 Aug 2006 17:33:36 -0400 Received: from [161.44.55.123] ([161.44.55.123]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 17:33:35 -0400 Message-ID: <44CFC8AF.3020900@cisco.com> Date: Tue, 01 Aug 2006 17:33:35 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] Hitchhikers guide - when is it done? References: <44C90241.9070806@lucent.com> In-Reply-To: <44C90241.9070806@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2006 21:33:35.0439 (UTC) FILETIME=[24E45DF0:01C6B5B2] DKIM-Signature: a=rsa-sha1; q=dns; l=1354; t=1154468017; x=1155332017; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Hitchhikers=20guide=20-=20when=20is=20it=20done?; X=v=3Dcisco.com=3B=20h=3DDpAaA9rWoxuoASPdrDDBO7lqI1E=3D; b=tHUjv3ItSmywUneTXpgRxij/5ZpqKP6UkhcifZzsalnmVCTA3EY+nw7s1TZg5Pfhq/STOnUC Pbnhehgq2eEMmDDW/fo1AQNsh15NwgTWs8ZFqhCU2SqUm2Eyc/cKKXRF; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF SIP List , "Romascanu, Dan \(Dan\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RFCs are the output of the IETF, nothing else. For this reason, I prefer generating an updated RFC once a year if needed, than trying to use an Internet Draft or a web page to capture the same information. When IETF figures out other processes for producing specifications, we can use that. For now, RFCs is what we've got. -Jonathan R. Vijay K. Gurbani wrote: > Romascanu, Dan (Dan) wrote: > >> I am aware about this. On the other hand, the problem with RFCs is that >> they tend to be updated at a slow pace. How often will the Hitchhiker >> Guide be updated? - every two, three years? > > > That is one reason why I was partial towards (1) from Jonathan's > original email. If we could get the core specification guide > out now as an RFC, we could tackle the extensions as an I-D, > which is much easier to rev than a RFC would be. Plus, the I-D > would be a WG agenda item, so that gives it some semblance > of permanence (as opposed to an individual I-D). > > Thanks, > > - vijay -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 01 18:03:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82Ir-0006yz-58; Tue, 01 Aug 2006 18:01:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82In-0006kZ-Fh; Tue, 01 Aug 2006 18:01:25 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G80zW-0004Hi-0V; Tue, 01 Aug 2006 16:37:26 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G80kc-0006fi-Qn; Tue, 01 Aug 2006 16:22:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id CD6722ACAF; Tue, 1 Aug 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G80Fd-0004zA-Ie; Tue, 01 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 01 Aug 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-10.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-gruu-10.txt Pages : 40 Date : 2006-8-1 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-gruu-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-1142307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-1142307.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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-- From sip-bounces@ietf.org Tue Aug 01 19:21:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G83Wg-00078t-7q; Tue, 01 Aug 2006 19:19:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G83We-00073b-Kv for sip@ietf.org; Tue, 01 Aug 2006 19:19:48 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G83Wc-00085F-Ab for sip@ietf.org; Tue, 01 Aug 2006 19:19:48 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A19A0444; Tue, 01 Aug 2006 19:19:54 -0400 From: "Hadriel Kaplan" To: "'Cullen Jennings'" Subject: RE: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Tue, 1 Aug 2006 19:19:44 -0400 Message-ID: <01ce01c6b5c0$f9760f10$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca1L6YD7c5FJ8JESzGDtniabhmvRQAim4dg In-Reply-To: X-Spam-Score: 1.2 (+) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Take a request going through A-B-C domains. A is the originating one, and signs the identity with A's cert. B uses b2bua's which would break the signature. I think I interpreted an earlier email from you to imply that a b2bua in a transit provider B should re-sign the identity with its own domain's (B's) certificate, if it would break the original signature. Was that correct? If so, my problem was: how would the final, receiving domain C decide to believe the signature, since it now uses B's cert to verify, which no longer matched the domain portion of the From URI (namely A). I think your answer to that, paraphrasing, was: "C has a relationship with B, not A, so C should trust/believe B's signature". Right? So then my problem is A-B-C-D. C passes the request to D. C did not own a b2bua, and did not need to re-sign it. So D gets a request that still has B's signature, and A's From URI domain. Why should D believe B's signature, when it only has a relationship to C? I think the answer is "it shouldn't". So my problem is how will we get this mechanism off the ground, when the most applicable/beneficial use cases for it (multi-domain transit) won't work? I am unconvinced it has any tangible value other than multi-domain cases. -hadriel p.s. IMO, Identity already isn't end-to-end, since it allows proxies to be the authenticator and verifier. It's domain-to-domain. The signing node is most likely already either after a b2bua, or a b2bua itself, which changed stuff (or could have). Likewise, the receiving domain verifier can be a b2bua or there could be one after it, which can change stuff. Obviously that's ok because the whole idea is the domain which signs it has "verified" the authenticity of the message through some means, and so it's as good as the domain's control is. But we shouldn't describe it as end-2-end, IMHO. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, August 01, 2006 1:59 AM > To: Hadriel Kaplan > Cc: 'Jonathan Rosenberg'; 'IETF SIP List' > Subject: Re: [Sip] Comments on rosenberg-sip-identity-coexistence > > > Keep in mind a B2BUA always breaks end to end security because the > B2BUA is the end. If C is only a proxy and does not have a b2bua, > everything seems to work find between B and D. I think I am missing > what the problem is here. I perfectly willing to believe there is a > problem - I just think that I am not clear yet on the scenario you > are thinking about. > > Cullen > > > On Jul 11, 2006, at 10:42 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > >> > >> Ok, I am done't think I am manging to explaim myself. Say A has a > >> contract with B and B has a crontract with C. Now a call arrives at > >> C, it seem that C wants a assertion to be made by B. Anything A says > >> to C is clsoe to useless because C has no clue who A even is. I guese > >> I feel like we need to sort out the requirements for what we want in > >> a transit case and then we might be able to figure out a solution. > > > > One of the problems with the idea of a b2bua re-signing it is how > > to trust > > the b2bua. I.e., if the domain the b2bua is in is not the same as the > > From's, then you have to somehow trust the different domain. I > > agree with > > you there's a common model of "I trust the domain connected to me > > directly". > > > > > > So if you have an A-B-C chain as you describe, then sure A can > > sign, then B > > can verify A and re-sign with B-cert, and C can verify B. Now imagine > > A-B-C-D; A and B have a b2bua, but C doesn't. A signs, then B > > verifies and > > signs with B-cert, C does nothing and D gets a From of A with a > > cert of B > > and does what? > > In other words, unless they all re-sign, it's limited to a small > > chain. But > > if they all re-sign, we're back to hop-by-hop trust. Well... fewer > > hops > > because it's domain-by-domain instead of proxy-by-proxy, so it is > > better. > > > > But is domain by domain resigning acceptable? It breaks the end-to- > > end > > model of identity, so I would think not. And making every domain > > re-sign > > would have a serious flag-day problem. (not to mention quite an > > impressive > > performance/scale issue I suspect) At the same time, in your > > example C does > > not have a contract with A, so the business model is not end-to-end > > - so I'm > > not sure why the trust would be. > > > > -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 02 05:14:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Cmq-0005M9-FE; Wed, 02 Aug 2006 05:13:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Cmp-0005M1-7D; Wed, 02 Aug 2006 05:13:07 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Cmn-0008Ks-UB; Wed, 02 Aug 2006 05:13:07 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 04:13:05 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 02 Aug 2006 04:13:05 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 04:13:04 -0500 Message-ID: From: "Dawson, Martin" To: "Ted Hardie" Date: Wed, 2 Aug 2006 04:13:02 -0500 Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 02 Aug 2006 09:13:04.0656 (UTC) FILETIME=[DC7EA900:01C6B613] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined Thread-Index: Aca1m9m7HhQ4R3f8SiOblllBRdk/NQAdfUOg X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Ted, This gets back to what I and others are in disagreement with. I don't agree with a SIP document specifying a list of approved geopriv using protocols. I also disagree that a location reference in a particular form actually indicate the protocol that will be used to do the de-reference operation. Your own example, in the strawman you submitted, showed how a http uri could reference a service which actually applies a geopriv-compliant set of semantics. It's also the case that it could be used to access a service that wasn't compliant.=20 Beyond that, if there was going to be a master set of approved protocols, it would be appropriately maintained as a geopriv document wouldn't it? SIP is not going to be the only conveyance protocol that could send a location reference around. Indeed, it isn't already since the V2 interface protocol defined in the NENA i2 specification is another example. It does not make sense from a maintenance perspective, to have to go around every conveyance protocol definition in the world and update them each time a new using protocol is defined. That is excessive coupling - and not good engineering. Cheers, Martin > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, 2 August 2006 4:54 AM > To: Andrew Newton; Winterbottom, James > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP > dereferencemechanism defined >=20 > At 9:03 PM -0400 7/31/06, Andrew Newton wrote: > > > >Brian is right. They are not the same issue, atleast they do not have to > be. > > > >From where I sit, I think the consensus is: > > - do not constrain the ABNF > > - HTTP goes in another document > > > >Keep in mind, my hat is labeled "GEOPRIV" and this is a SIP document. >=20 > I agree with the "HTTP goes in another document" statement of consensus > (and the consensus appears to be that HTTP MUST be a using protocol). >=20 > I think "do not constrain the ABNF" is not the right formulation though; I > think the consensus is: "limit URI schemes to those approved here or in > subsequent > documents for this use". >=20 > There are a variety of ways to make the ABNF say the latter, but the key > difference > is that it will always be a constrained list, but the list will grow over > time. >=20 > I would not be happy with a unconstrained ABNF, as there are lots of URI > schemes > that would not make sense here (tag? info? opaquelocktocken? mid? > modem?). >=20 > I am wearing no hats here. > Ted >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 02 08:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8GID-0007Fu-Pk; Wed, 02 Aug 2006 08:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8GIC-0007B8-9p; Wed, 02 Aug 2006 08:57:44 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8GIA-00029y-VI; Wed, 02 Aug 2006 08:57:44 -0400 Received: from [192.168.0.41] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k72CvdMp015633 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 2 Aug 2006 08:57:40 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72FD8752-C3B2-409B-9909-A529F8443241@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined Date: Wed, 2 Aug 2006 08:57:32 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.2.54432 X-PerlMx-Spam: Gauge=XXII, Probability=22%, Report='RELAY_IN_NJABL_DYNABLOCK 2.5, RCVD_IN_NJABL_ORG 0, RELAY_IN_NJABL_ORG 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RELAY_IN_NJABL_DYNABLOCK 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Ted Hardie , IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'll also re-iterate and rephrase another point made by somebody else before: Restricting URL schemes makes the system non-upgradeable. If a proxy supports "RFC-conveyance" that restricts URLs to a particular scheme list, it will have to reject as flawed a request that contains a newly-defined protocol it doesn't yet know about. Thus, reliably introducing a new protocol would have to wait until every location- aware proxy in the world has been upgraded, which I hope we agree is untenable. The right model is that a proxy that doesn't implement or doesn't want to support (by policy) a certain URL scheme is to ignore it. SIP always has strived to make it possible to evolve systems incrementally, so this type of restriction is well outside established SIP design practice. Henning On Aug 2, 2006, at 5:13 AM, Dawson, Martin wrote: > Hi Ted, > > This gets back to what I and others are in disagreement with. > > I don't agree with a SIP document specifying a list of approved > geopriv > using protocols. I also disagree that a location reference in a > particular form actually indicate the protocol that will be used to do > the de-reference operation. Your own example, in the strawman you > submitted, showed how a http uri could reference a service which > actually applies a geopriv-compliant set of semantics. It's also the > case that it could be used to access a service that wasn't compliant. > > Beyond that, if there was going to be a master set of approved > protocols, it would be appropriately maintained as a geopriv document > wouldn't it? > > SIP is not going to be the only conveyance protocol that could send a > location reference around. Indeed, it isn't already since the V2 > interface protocol defined in the NENA i2 specification is another > example. > > It does not make sense from a maintenance perspective, to have to go > around every conveyance protocol definition in the world and update > them > each time a new using protocol is defined. That is excessive > coupling - > and not good engineering. > > Cheers, > Martin > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Wednesday, 2 August 2006 4:54 AM >> To: Andrew Newton; Winterbottom, James >> Cc: IETF SIP List; Rosen, Brian; GEOPRIV >> Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an >> HTTP >> dereferencemechanism defined >> >> At 9:03 PM -0400 7/31/06, Andrew Newton wrote: >>> >>> Brian is right. They are not the same issue, atleast they do not > have to >> be. >>> >>> From where I sit, I think the consensus is: >>> - do not constrain the ABNF >>> - HTTP goes in another document >>> >>> Keep in mind, my hat is labeled "GEOPRIV" and this is a SIP >>> document. >> >> I agree with the "HTTP goes in another document" statement of > consensus >> (and the consensus appears to be that HTTP MUST be a using protocol). >> >> I think "do not constrain the ABNF" is not the right formulation > though; I >> think the consensus is: "limit URI schemes to those approved here or > in >> subsequent >> documents for this use". >> >> There are a variety of ways to make the ABNF say the latter, but the > key >> difference >> is that it will always be a constrained list, but the list will grow > over >> time. >> >> I would not be happy with a unconstrained ABNF, as there are lots of > URI >> schemes >> that would not make sense here (tag? info? opaquelocktocken? mid? >> modem?). >> >> I am wearing no hats here. >> Ted >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 02 09:26:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8GiK-0001sT-OP; Wed, 02 Aug 2006 09:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8GiJ-0001sI-B3; Wed, 02 Aug 2006 09:24:43 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8GiH-0005PD-4B; Wed, 02 Aug 2006 09:24:43 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 02 Aug 2006 09:24:47 -0400 id 01588183.44D0A7A0.00006F5B Message-ID: <44D0A790.4060808@hxr.us> Date: Wed, 02 Aug 2006 09:24:32 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined References: <72FD8752-C3B2-409B-9909-A529F8443241@cs.columbia.edu> In-Reply-To: <72FD8752-C3B2-409B-9909-A529F8443241@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Ted Hardie , "Dawson, Martin" , IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henning Schulzrinne wrote: > I'll also re-iterate and rephrase another point made by somebody else > before: Restricting URL schemes makes the system non-upgradeable. If a > proxy supports "RFC-conveyance" that restricts URLs to a particular > scheme list, it will have to reject as flawed a request that contains a > newly-defined protocol it doesn't yet know about. Thus, reliably > introducing a new protocol would have to wait until every location-aware > proxy in the world has been upgraded, which I hope we agree is > untenable. The right model is that a proxy that doesn't implement or > doesn't want to support (by policy) a certain URL scheme is to ignore > it. SIP always has strived to make it possible to evolve systems > incrementally, so this type of restriction is well outside established > SIP design practice. Henning, these are separable issues. Codification of rejection of unknown URI schemes and maintenance of a list sanctioned schemes are two different things. -andy _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 02 10:31:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8HjI-0007Ep-Fv; Wed, 02 Aug 2006 10:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8HjG-0007Eb-AB for sip@ietf.org; Wed, 02 Aug 2006 10:29:46 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8HjE-0001Q4-M2 for sip@ietf.org; Wed, 02 Aug 2006 10:29:46 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Aug 2006 07:29:44 -0700 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.20060308/8.12.11) with ESMTP id k72ETip2014468; Wed, 2 Aug 2006 07:29:44 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k72ETi2D021104; Wed, 2 Aug 2006 07:29:44 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k72EMRZx002450; Wed, 2 Aug 2006 07:22:27 -0700 In-Reply-To: <01ce01c6b5c0$f9760f10$6601a8c0@acmepacket.com> References: <01ce01c6b5c0$f9760f10$6601a8c0@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CF181E9-98AA-4B12-A6A2-964D9C4BC478@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Wed, 2 Aug 2006 10:29:37 -0400 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-2.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=5656; t=1154528984; x=1155392984; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20rosenberg-sip-identity-coexistence; X=v=3Dcisco.com=3B=20h=3DCKTqMJaXBDJScvy6cNgnvNoKgA4=3D; b=juJHpraOm8JENYIfnwALnaGD/hnGRkHE1/X1ld2lnqsGsAJOjQV1tN9IREPvPLJ8ghBjJciq IQVS+gu6qDXd/kvBtYl41B1nT2wI5g49gMG6i3LQQZxsZm8HfmP3iyU3; X-Spam-Score: 1.1 (+) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: 'Cullen Jennings' , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 1, 2006, at 7:19 PM, Hadriel Kaplan wrote: > Take a request going through A-B-C domains. A is the originating > one, and > signs the identity with A's cert. B uses b2bua's which would break > the > signature. I think I interpreted an earlier email from you to > imply that a > b2bua in a transit provider B should re-sign the identity with its own > domain's (B's) certificate, if it would break the original > signature. Was > that correct? > > If so, my problem was: how would the final, receiving domain C > decide to > believe the signature, since it now uses B's cert to verify, which > no longer > matched the domain portion of the From URI (namely A). I think > your answer > to that, paraphrasing, was: "C has a relationship with B, not A, so > C should > trust/believe B's signature". Right? > > So then my problem is A-B-C-D. C passes the request to D. C did > not own a > b2bua, and did not need to re-sign it. So D gets a request that > still has > B's signature, and A's From URI domain. Why should D believe B's > signature, > when it only has a relationship to C? > Transitive trust. D has to assume C checked B's signature and was satisfied enough to re-initiate the SIP dialog it got from B. Transitive trust sucks, but given that a B2BUA is basically an unverifiable Turing machine this is the best you can do in the absence of a PKI-based chain of trust. > I think the answer is "it shouldn't". So my problem is how will we > get this > mechanism off the ground, when the most applicable/beneficial use > cases for > it (multi-domain transit) won't work? I am unconvinced it has any > tangible > value other than multi-domain cases. > I'm unconvinced why we need to support transit in the first place, but that's another can of very large and aggressive c.elegans. > -hadriel > > p.s. IMO, Identity already isn't end-to-end, since it allows > proxies to be > the authenticator and verifier. It's domain-to-domain. The > signing node is > most likely already either after a b2bua, or a b2bua itself, which > changed > stuff (or could have). Likewise, the receiving domain verifier can > be a > b2bua or there could be one after it, which can change stuff. > Obviously > that's ok because the whole idea is the domain which signs it has > "verified" > the authenticity of the message through some means, and so it's as > good as > the domain's control is. But we shouldn't describe it as end-2- > end, IMHO. > > > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Tuesday, August 01, 2006 1:59 AM >> To: Hadriel Kaplan >> Cc: 'Jonathan Rosenberg'; 'IETF SIP List' >> Subject: Re: [Sip] Comments on rosenberg-sip-identity-coexistence >> >> >> Keep in mind a B2BUA always breaks end to end security because the >> B2BUA is the end. If C is only a proxy and does not have a b2bua, >> everything seems to work find between B and D. I think I am missing >> what the problem is here. I perfectly willing to believe there is a >> problem - I just think that I am not clear yet on the scenario you >> are thinking about. >> >> Cullen >> >> >> On Jul 11, 2006, at 10:42 PM, Hadriel Kaplan wrote: >> >>>> -----Original Message----- >>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>> >>>> Ok, I am done't think I am manging to explaim myself. Say A has a >>>> contract with B and B has a crontract with C. Now a call arrives at >>>> C, it seem that C wants a assertion to be made by B. Anything A >>>> says >>>> to C is clsoe to useless because C has no clue who A even is. I >>>> guese >>>> I feel like we need to sort out the requirements for what we >>>> want in >>>> a transit case and then we might be able to figure out a solution. >>> >>> One of the problems with the idea of a b2bua re-signing it is how >>> to trust >>> the b2bua. I.e., if the domain the b2bua is in is not the same >>> as the >>> From's, then you have to somehow trust the different domain. I >>> agree with >>> you there's a common model of "I trust the domain connected to me >>> directly". >>> >>> >>> So if you have an A-B-C chain as you describe, then sure A can >>> sign, then B >>> can verify A and re-sign with B-cert, and C can verify B. Now >>> imagine >>> A-B-C-D; A and B have a b2bua, but C doesn't. A signs, then B >>> verifies and >>> signs with B-cert, C does nothing and D gets a From of A with a >>> cert of B >>> and does what? >>> In other words, unless they all re-sign, it's limited to a small >>> chain. But >>> if they all re-sign, we're back to hop-by-hop trust. Well... fewer >>> hops >>> because it's domain-by-domain instead of proxy-by-proxy, so it is >>> better. >>> >>> But is domain by domain resigning acceptable? It breaks the end-to- >>> end >>> model of identity, so I would think not. And making every domain >>> re-sign >>> would have a serious flag-day problem. (not to mention quite an >>> impressive >>> performance/scale issue I suspect) At the same time, in your >>> example C does >>> not have a contract with A, so the business model is not end-to-end >>> - so I'm >>> not sure why the trust would be. >>> >>> -hadriel > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 02 11:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IV1-0002n9-VW; Wed, 02 Aug 2006 11:19:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IV1-0002mc-0B; Wed, 02 Aug 2006 11:19:07 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8IUy-0006q8-PI; Wed, 02 Aug 2006 11:19:06 -0400 Received: from lion.cs.columbia.edu (IDENT:UrtrT06U5w6Hc5W5yMMIVQLH1d+RT9iN@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k72FJ3f7009768 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 2 Aug 2006 11:19:03 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k72FJ2rh026491 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Aug 2006 11:19:03 -0400 Message-ID: <44D0C261.1050501@cs.columbia.edu> Date: Wed, 02 Aug 2006 11:18:57 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: SIP working group , GEOPRIV working group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.2.74933 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Sip] Location header name collides with HTTP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just to throw another curveball: I don't know why nobody has noticed this before, but the definition of Location in draft-ietf-sip-location-conveyance-03 directly conflicts with the HTTP usage of the same header name (section 14.30 of RFC 2616). While the two name spaces are nominally different, I think it is a fundamentally bad idea to collide with the HTTP name space and re-use the same header name for dramatically different content. (Among other reasons, we might want to use the same (geo/civic) location mechanism in RTSP or even HTTP later, and it would be really confusing to have different names in each protocol.) Since there's no shortage of English words, this should be changed. By the way, we had this discussion early on in SIP, yielding the Contact header (instead of, as it happens, Location, although the concepts were much closer). For some reason, HTTP seems to have survived without disallowing the "fax" URI scheme... Henning _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 02 11:30:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IeK-0004Ah-8J; Wed, 02 Aug 2006 11:28:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IeJ-0004AM-1s; Wed, 02 Aug 2006 11:28:43 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8IeH-0000MU-OX; Wed, 02 Aug 2006 11:28:43 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G8IeA-0004f3-NC; Wed, 02 Aug 2006 10:28:35 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'SIP working group'" , "'GEOPRIV working group'" Date: Wed, 2 Aug 2006 11:28:38 -0400 Message-ID: <08da01c6b648$541c5000$640fa8c0@cis.neustar.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: <44D0C261.1050501@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca2Rv8SBzLtHvMmSuSYqxXXxdceiQAAGuGw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Sip] RE: [Geopriv] Location header name collides with HTTP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James is on vacation, so I want to wait until he returns but I agree with you. Would "Geolocation" be acceptable? It does sometimes make you think we only mean lat/lon, instead of also allowing street address, but it's technically accurate. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, August 02, 2006 11:19 AM > To: SIP working group; GEOPRIV working group > Subject: [Geopriv] Location header name collides with HTTP > > Just to throw another curveball: > > I don't know why nobody has noticed this before, but the definition of > Location in draft-ietf-sip-location-conveyance-03 directly conflicts > with the HTTP usage of the same header name (section 14.30 of RFC 2616). > > While the two name spaces are nominally different, I think it is a > fundamentally bad idea to collide with the HTTP name space and re-use > the same header name for dramatically different content. (Among other > reasons, we might want to use the same (geo/civic) location mechanism in > RTSP or even HTTP later, and it would be really confusing to have > different names in each protocol.) > > Since there's no shortage of English words, this should be changed. > > By the way, we had this discussion early on in SIP, yielding the Contact > header (instead of, as it happens, Location, although the concepts were > much closer). > > For some reason, HTTP seems to have survived without disallowing the > "fax" URI scheme... > > Henning > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 02 11:34:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Ihu-0006mf-9I; Wed, 02 Aug 2006 11:32:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Ihs-0006mY-D4 for sip@ietf.org; Wed, 02 Aug 2006 11:32:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Ihr-0000Wm-0S for sip@ietf.org; Wed, 02 Aug 2006 11:32:24 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 02 Aug 2006 08:32:22 -0700 X-IronPort-AV: i="4.07,205,1151910000"; d="scan'208"; a="309396784:sNHT35658272" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k72FWMUC020354 for ; Wed, 2 Aug 2006 08:32:22 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k72FWKmW015150 for ; Wed, 2 Aug 2006 08:32:22 -0700 (PDT) Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 11:32:21 -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 Subject: RE: [Sip] updated acr code draft Date: Wed, 2 Aug 2006 11:32:21 -0400 Message-ID: <8983EC086A9D954BA74D9763E853CF3E01E4B492@xmb-rtp-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] updated acr code draft Thread-Index: Aca04D9/nAnmysWAQzyVZD1RMwAgNgBZ08iQ From: "Sanjay Sinha \(sanjsinh\)" To: "Jonathan Rosenberg \(jdrosen\)" , "IETF SIP List" X-OriginalArrivalTime: 02 Aug 2006 15:32:21.0500 (UTC) FILETIME=[D8A17BC0:01C6B648] DKIM-Signature: a=rsa-sha1; q=dns; l=1603; t=1154532742; x=1155396742; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=22Sanjay=20Sinha=20\(sanjsinh\)=22=20 |Subject:RE=3A=20[Sip]=20updated=20acr=20code=20draft; X=v=3Dcisco.com=3B=20h=3DDtHVIclurRbhyZd+sk1Wc6sk1yw=3D; b=TGu176uS1eoJgJOwgYrTNiXaMdMTL1jMHGTooqy5gd3x+JHZdddSBdlLfLJmHNALBg6wqgVx Mzxac8N+A7vA+AWCsvd/SRv8Rn9/VyWN6QIITBsPCFaXLQBIjr4x7Rrr; Authentication-Results: sj-dkim-5.cisco.com; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What about the case in which caller information is not available at the time INVITE is sent to establish a call, but is available later and an UPDATE/INFO is sent by UAC to update the caller-id information. If UAS rejects UPDATE/INFO with 433, what does it mean for the Invite dialog. Should that also be terminated as a result of ACR? Thanks Sanjay -----Original Message----- From: Jonathan Rosenberg (jdrosen)=20 Sent: Monday, July 31, 2006 4:31 PM To: IETF SIP List Subject: [Sip] updated acr code draft I've submitted a minor update to the ACR code draft. Until it appears, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt the changes are: * replaced P-Asserted-ID with P-Asserted-Identity * added to security considerations section, consideration for anonymizers in the network. Namely, don't retry request on receipt of 433 unless explicitly configured to do so by user Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 02 11:34:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IiY-000742-Dd; Wed, 02 Aug 2006 11:33:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IiW-00072w-Gr for sip@ietf.org; Wed, 02 Aug 2006 11:33:04 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8IiU-0000iK-2W for sip@ietf.org; Wed, 02 Aug 2006 11:33:04 -0400 Received: (qmail 28426 invoked by uid 0); 2 Aug 2006 15:33:00 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 Aug 2006 15:33:00 -0000 Message-ID: <075e01c6b648$ef23f710$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Brian Rosen" , "'Henning Schulzrinne'" , "'SIP working group'" , "'GEOPRIV working group'" References: <08da01c6b648$541c5000$640fa8c0@cis.neustar.com> Subject: Re: [Sip] RE: [Geopriv] Location header name collides with HTTP Date: Wed, 2 Aug 2006 17:32:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Suggestion: "Location-Object" Jeroen > James is on vacation, so I want to wait until he returns but I agree with > you. Would "Geolocation" be acceptable? It does sometimes make you think > we > only mean lat/lon, instead of also allowing street address, but it's > technically accurate. > > Brian >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Wednesday, August 02, 2006 11:19 AM >> To: SIP working group; GEOPRIV working group >> Subject: [Geopriv] Location header name collides with HTTP >> >> Just to throw another curveball: >> >> I don't know why nobody has noticed this before, but the definition of >> Location in draft-ietf-sip-location-conveyance-03 directly conflicts >> with the HTTP usage of the same header name (section 14.30 of RFC 2616). >> >> While the two name spaces are nominally different, I think it is a >> fundamentally bad idea to collide with the HTTP name space and re-use >> the same header name for dramatically different content. (Among other >> reasons, we might want to use the same (geo/civic) location mechanism in >> RTSP or even HTTP later, and it would be really confusing to have >> different names in each protocol.) >> >> Since there's no shortage of English words, this should be changed. >> >> By the way, we had this discussion early on in SIP, yielding the Contact >> header (instead of, as it happens, Location, although the concepts were >> much closer). >> >> For some reason, HTTP seems to have survived without disallowing the >> "fax" URI scheme... >> >> Henning >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 02 11:40:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Io9-0005Id-6N; Wed, 02 Aug 2006 11:38:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Io7-0005IV-BD; Wed, 02 Aug 2006 11:38:51 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Io4-0001HL-45; Wed, 02 Aug 2006 11:38:51 -0400 Received: from lion.cs.columbia.edu (IDENT:nAGwjDnG62GEhB0OX1ArvP/ajojJ6pI6@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k72Fcff7013609 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 2 Aug 2006 11:38:41 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k72Fcfrh027761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Aug 2006 11:38:41 -0400 Message-ID: <44D0C6FC.9030808@cs.columbia.edu> Date: Wed, 02 Aug 2006 11:38:36 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Rosen References: <08da01c6b648$541c5000$640fa8c0@cis.neustar.com> In-Reply-To: <08da01c6b648$541c5000$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.2.81933 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='WEIRD_PORT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'SIP working group' , 'GEOPRIV working group' Subject: [Sip] Re: [Geopriv] Location header name collides with HTTP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Geolocation works for me, at least until we have to describe lunar coordinates. A number of other headers have been proposed, such as http://www.crs4.it:8000/gpsweb/26 http://geotags.com/geo/draft-daviel-kaegi-http-geo-header-05.html These names are also best avoided. Brian Rosen wrote: > James is on vacation, so I want to wait until he returns but I agree with > you. Would "Geolocation" be acceptable? It does sometimes make you think we > only mean lat/lon, instead of also allowing street address, but it's > technically accurate. > > Brian _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 02 14:54:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8LpQ-00014U-Ow; Wed, 02 Aug 2006 14:52:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8LpP-00010C-OO; Wed, 02 Aug 2006 14:52:23 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8LpO-0005OX-DL; Wed, 02 Aug 2006 14:52:23 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k72IqAPJ026383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2006 11:52:10 -0700 Received: from [10.0.1.4] (dhcp-campbell-87.qualcomm.com [129.46.225.24]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k72Iq80U016736; Wed, 2 Aug 2006 11:52:08 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44D0A790.4060808@hxr.us> References: <72FD8752-C3B2-409B-9909-A529F8443241@cs.columbia.edu> <44D0A790.4060808@hxr.us> Date: Wed, 2 Aug 2006 11:52:06 -0700 To: Andrew Newton , Henning Schulzrinne From: Ted Hardie Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.6 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF SIP List , "Dawson, Martin" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 9:24 AM -0400 8/2/06, Andrew Newton wrote: >Henning Schulzrinne wrote: >>I'll also re-iterate and rephrase another point made by somebody else before: Restricting URL schemes makes the system non-upgradeable. If a proxy supports "RFC-conveyance" that restricts URLs to a particular scheme list, it will have to reject as flawed a request that contains a newly-defined protocol it doesn't yet know about. Thus, reliably introducing a new protocol would have to wait until every location-aware proxy in the world has been upgraded, which I hope we agree is untenable. The right model is that a proxy that doesn't implement or doesn't want to support (by policy) a certain URL scheme is to ignore it. SIP always has strived to make it possible to evolve systems incrementally, so this type of restriction is well outside established SIP design practice. > >Henning, these are separable issues. Codification of rejection of unknown URI schemes and maintenance of a list sanctioned schemes are two different things. > Henning, What difference do you see between the proxy behavior when something is rejected as "flawed" because it contains a newly defined protocol and proxy behavior when the URL scheme list is open and the proxy encounters one it does not understand? Ted _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 02 14:59:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8LuQ-0005Vp-Vs; Wed, 02 Aug 2006 14:57:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8LuQ-0005Vh-26; Wed, 02 Aug 2006 14:57:34 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8LuN-0005h2-RH; Wed, 02 Aug 2006 14:57:34 -0400 Received: from lion.cs.columbia.edu (IDENT:bRP/y37VQU4+9zg31flDvzbZzR64zfhl@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k72IvTf7024639 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 2 Aug 2006 14:57:29 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k72IvQrh007964 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Aug 2006 14:57:27 -0400 Message-ID: <44D0F591.6060700@cs.columbia.edu> Date: Wed, 02 Aug 2006 14:57:21 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined References: <72FD8752-C3B2-409B-9909-A529F8443241@cs.columbia.edu> <44D0A790.4060808@hxr.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.2.113932 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.6 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF SIP List , "Dawson, Martin" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > What difference do you see between the proxy behavior when something > is rejected as "flawed" because it contains a newly defined protocol and proxy behavior > when the URL scheme list is open and the proxy encounters one it does not understand? There are three cases, in general: - "flawed" -> reject request with 4xx error - "don't understand any" -> ignore (and maybe special-case route it to some smart entity that might) or generate error - "don't understand one of the schemes" -> ignore and pick one you understand I'm assuming a model where a request may contain multiple location references, just like LoST responses can point to multiple PSAP URI schemes. That, by the way, is the level of detail that the draft might want to have and seems to be leaving somewhat under-defined. > > Ted _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 02 15:05:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8M0U-0002Bt-An; Wed, 02 Aug 2006 15:03:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8M0S-0002Bk-K1; Wed, 02 Aug 2006 15:03:48 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8M0Q-0005zp-D4; Wed, 02 Aug 2006 15:03:48 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Wed, 02 Aug 2006 15:03:52 -0400 id 01588193.44D0F719.00002FB7 Message-ID: <44D0F709.3050506@hxr.us> Date: Wed, 02 Aug 2006 15:03:37 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined References: <72FD8752-C3B2-409B-9909-A529F8443241@cs.columbia.edu> <44D0A790.4060808@hxr.us> <44D0F591.6060700@cs.columbia.edu> In-Reply-To: <44D0F591.6060700@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Ted Hardie , "Dawson, Martin" , IETF SIP List , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henning Schulzrinne wrote: > There are three cases, in general: > > - "flawed" -> reject request with 4xx error > > - "don't understand any" -> ignore (and maybe special-case route it to > some smart entity that might) or generate error The other case for "don't understand any" could be reject. To reject or ignore or smart-host forward would be a matter of local policy. > > - "don't understand one of the schemes" -> ignore and pick one you > understand > > I'm assuming a model where a request may contain multiple location > references, just like LoST responses can point to multiple PSAP URI > schemes. > > That, by the way, is the level of detail that the draft might want to > have and seems to be leaving somewhat under-defined. Very definitely agreed. Thanks for the mental exploration. -andy _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 02 15:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Mcg-0007re-CC; Wed, 02 Aug 2006 15:43:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Mcf-0007q2-22; Wed, 02 Aug 2006 15:43:17 -0400 Received: from tpamail2.verizon.com ([192.76.82.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Mcd-000801-Gd; Wed, 02 Aug 2006 15:43:17 -0400 Received: from smtpirv2.verizon.com (smtpirv2.verizon.com [138.83.34.66]) by tpamail2.verizon.com (8.13.3/8.13.3) with ESMTP id k72JhCnt028061; Wed, 2 Aug 2006 15:43:12 -0400 (EDT) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by smtpirv2.verizon.com (8.13.3/8.13.3) with ESMTP id k72Jeddg016379; Wed, 2 Aug 2006 14:40:39 -0500 (CDT) Received: from coregate1.verizon.com (unknown [138.83.34.22]) by tpaintrmemf3.verizon.com (Symantec Mail Security) with ESMTP id 521F5444018; Wed, 2 Aug 2006 15:43:11 -0400 (EDT) Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id k72JhA4A006833; Wed, 2 Aug 2006 14:43:11 -0500 (CDT) Subject: Fw: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined Sensitivity: To: sip@ietf.org, geopriv@ietf.org X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gary.m.sacra@verizon.com Date: Wed, 2 Aug 2006 15:43:03 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.5.4HF453 | August 4, 2005) at 08/02/2006 14:43:10 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: michael.g.armstrong@verizon.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We concur with Henning's statements below and are supportive of no restriction on the URI scheme for expressing a location reference in the SIP location conveyance draft. Regards, Gary Sacra Michael Armstrong Verizon ----- Forwarded by GARY M. SACRA/EMPL/MD/Verizon on 08/02/2006 02:37 PM ----- "Henning Schulzrinne" "Dawson, Martin" 08/02/2006 08:57 cc AM "Ted Hardie" , "IETF SIP List" , "GEOPRIV" Subject Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined I'll also re-iterate and rephrase another point made by somebody else before: Restricting URL schemes makes the system non-upgradeable. If a proxy supports "RFC-conveyance" that restricts URLs to a particular scheme list, it will have to reject as flawed a request that contains a newly-defined protocol it doesn't yet know about. Thus, reliably introducing a new protocol would have to wait until every location- aware proxy in the world has been upgraded, which I hope we agree is untenable. The right model is that a proxy that doesn't implement or doesn't want to support (by policy) a certain URL scheme is to ignore it. SIP always has strived to make it possible to evolve systems incrementally, so this type of restriction is well outside established SIP design practice. Henning On Aug 2, 2006, at 5:13 AM, Dawson, Martin wrote: > Hi Ted, > > This gets back to what I and others are in disagreement with. > > I don't agree with a SIP document specifying a list of approved > geopriv > using protocols. I also disagree that a location reference in a > particular form actually indicate the protocol that will be used to do > the de-reference operation. Your own example, in the strawman you > submitted, showed how a http uri could reference a service which > actually applies a geopriv-compliant set of semantics. It's also the > case that it could be used to access a service that wasn't compliant. > > Beyond that, if there was going to be a master set of approved > protocols, it would be appropriately maintained as a geopriv document > wouldn't it? > > SIP is not going to be the only conveyance protocol that could send a > location reference around. Indeed, it isn't already since the V2 > interface protocol defined in the NENA i2 specification is another > example. > > It does not make sense from a maintenance perspective, to have to go > around every conveyance protocol definition in the world and update > them > each time a new using protocol is defined. That is excessive > coupling - > and not good engineering. > > Cheers, > Martin > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Wednesday, 2 August 2006 4:54 AM >> To: Andrew Newton; Winterbottom, James >> Cc: IETF SIP List; Rosen, Brian; GEOPRIV >> Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an >> HTTP >> dereferencemechanism defined >> >> At 9:03 PM -0400 7/31/06, Andrew Newton wrote: >>> >>> Brian is right. They are not the same issue, atleast they do not > have to >> be. >>> >>> From where I sit, I think the consensus is: >>> - do not constrain the ABNF >>> - HTTP goes in another document >>> >>> Keep in mind, my hat is labeled "GEOPRIV" and this is a SIP >>> document. >> >> I agree with the "HTTP goes in another document" statement of > consensus >> (and the consensus appears to be that HTTP MUST be a using protocol). >> >> I think "do not constrain the ABNF" is not the right formulation > though; I >> think the consensus is: "limit URI schemes to those approved here or > in >> subsequent >> documents for this use". >> >> There are a variety of ways to make the ABNF say the latter, but the > key >> difference >> is that it will always be a constrained list, but the list will grow > over >> time. >> >> I would not be happy with a unconstrained ABNF, as there are lots of > URI >> schemes >> that would not make sense here (tag? info? opaquelocktocken? mid? >> modem?). >> >> I am wearing no hats here. >> Ted >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 02 18:13:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Ovq-0005tx-MK; Wed, 02 Aug 2006 18:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Ovo-0005q3-Im for sip@ietf.org; Wed, 02 Aug 2006 18:11:12 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Ovn-0001qo-9z for sip@ietf.org; Wed, 02 Aug 2006 18:11:12 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.6/IER-o) with ESMTP id k72MBAPZ021035; Wed, 2 Aug 2006 17:11:11 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k72MBAx14548; Wed, 2 Aug 2006 17:11:10 -0500 (CDT) Message-ID: <44D122FE.4060501@lucent.com> Date: Wed, 02 Aug 2006 17:11:10 -0500 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'Alan Jeffrey' Subject: [Sip] -03 version for domain-certs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks: Based on the conversation we had in the SIP WG in Montreal on domain-certs, and the ensuing hallway and side- conversations, domain-certs has been updated. Until it becomes available in the archives, you can get a copy from: http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/domain-certs/draft-gurbani-sip-domain-certs-03.txt http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/domain-certs/draft-gurbani-sip-domain-certs-03.html The draft has benefited from comments received during the WG meeting, and as a result, this revision is much more focused on the problem and a solution. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 03 01:54:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8W8E-00045O-1C; Thu, 03 Aug 2006 01:52:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8W8C-00045J-JK for sip@ietf.org; Thu, 03 Aug 2006 01:52:28 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8W8A-0005lD-45 for sip@ietf.org; Thu, 03 Aug 2006 01:52:28 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 3 Aug 2006 07:52:24 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Aug 2006 07:52:24 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A6C3@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: sanjsinh@cisco.com, jdrosen@cisco.com, sip@ietf.org Subject: AW: [Sip] updated acr code draft Date: Thu, 3 Aug 2006 07:52:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The ACR service itself reacts only on identities that are put anonymus = by the user or on behalf on the user. So if the restriction is based on other reasons ACR will not terminate = the call. My question to your scenario is in which case an identity is not = available in an INVITE. The From header is an mandatory header so the = >From Header has have an user identity. Or not? The P-Asserted-Identity is set by an trusted network entity that is = aware of the user sending that request. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com]=20 > Gesendet: Mittwoch, 2. August 2006 17:32 > An: Jonathan Rosenberg (jdrosen); IETF SIP List > Betreff: RE: [Sip] updated acr code draft >=20 >=20 > What about the case in which caller information is not=20 > available at the > time INVITE is sent to establish a call, but is available later and = an > UPDATE/INFO is sent by UAC to update the caller-id information. If = UAS > rejects UPDATE/INFO with 433, what does it mean for the Invite = dialog. > Should that also be terminated as a result of ACR? >=20 > Thanks > Sanjay >=20 > -----Original Message----- > From: Jonathan Rosenberg (jdrosen)=20 > Sent: Monday, July 31, 2006 4:31 PM > To: IETF SIP List > Subject: [Sip] updated acr code draft >=20 > I've submitted a minor update to the ACR code draft. Until it = appears, > you can pick it up at: >=20 > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt >=20 > the changes are: >=20 > * replaced P-Asserted-ID with P-Asserted-Identity >=20 > * added to security considerations section, consideration for > anonymizers in the network. Namely, don't retry request on receipt of > 433 unless explicitly configured to do so by user >=20 >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 03 09:58:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8dgu-0000It-UW; Thu, 03 Aug 2006 09:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8dgt-0000CE-Bu for sip@ietf.org; Thu, 03 Aug 2006 09:56:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8dgr-00084o-VY for sip@ietf.org; Thu, 03 Aug 2006 09:56:47 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2006 06:56:45 -0700 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.20060308/8.12.11) with ESMTP id k73Dui5u012584; Thu, 3 Aug 2006 06:56:44 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k73DugBk001874; Thu, 3 Aug 2006 06:56:44 -0700 (PDT) Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 09:56:44 -0400 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 Subject: RE: [Sip] updated acr code draft Date: Thu, 3 Aug 2006 09:56:43 -0400 Message-ID: <8983EC086A9D954BA74D9763E853CF3E01E4B7A8@xmb-rtp-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] updated acr code draft Thread-Index: Aca2wQlZzxzX0XT4QIaOaBs1IzqbXQAQ2c2Q From: "Sanjay Sinha \(sanjsinh\)" To: "Jesske, R" , "Jonathan Rosenberg \(jdrosen\)" , X-OriginalArrivalTime: 03 Aug 2006 13:56:44.0051 (UTC) FILETIME=[A741FE30:01C6B704] DKIM-Signature: a=rsa-sha1; q=dns; l=3544; t=1154613405; x=1155477405; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=22Sanjay=20Sinha=20\(sanjsinh\)=22=20 |Subject:RE=3A=20[Sip]=20updated=20acr=20code=20draft; X=v=3Dcisco.com=3B=20h=3Dcu83S0K/wkj/W0y9tgwJf03By5E=3D; b=ewSvOR0JmdQ49huTNeQilcoUflR1ip1eNXQpGMCExq5oiarzl3BH9wEpbv2AmJmV3WoZ4pWz AHER3EFlfgpZbmfqEYaVb+enIPhqu0JhAmOifNZWljgjekggg43NHTIE; Authentication-Results: sj-dkim-1.cisco.com; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Scenario is PSTN-SIP interworking. For some cases, display IE is not = available in SETUP because some TCAP query is required. When the query = is complete, switch sends display IE in a FACILITY message. From header = is mandatory in INVITE, but calling name and number is not. So Invite is = sent without caller-identity which is later updated with an UPDATE/INFO, = when the UA gets FACILITY with display information. Thanks Sanjay.=20 -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: Thursday, August 03, 2006 1:52 AM To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen); sip@ietf.org Subject: AW: [Sip] updated acr code draft The ACR service itself reacts only on identities that are put anonymus = by the user or on behalf on the user. So if the restriction is based on other reasons ACR will not terminate = the call. My question to your scenario is in which case an identity is not = available in an INVITE. The From header is an mandatory header so the = >From Header has have an user identity. Or not? The P-Asserted-Identity is set by an trusted network entity that is = aware of the user sending that request. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > Gesendet: Mittwoch, 2. August 2006 17:32 > An: Jonathan Rosenberg (jdrosen); IETF SIP List > Betreff: RE: [Sip] updated acr code draft >=20 >=20 > What about the case in which caller information is not available at=20 > the time INVITE is sent to establish a call, but is available later=20 > and an UPDATE/INFO is sent by UAC to update the caller-id information. = > If UAS rejects UPDATE/INFO with 433, what does it mean for the Invite=20 > dialog. > Should that also be terminated as a result of ACR? >=20 > Thanks > Sanjay >=20 > -----Original Message----- > From: Jonathan Rosenberg (jdrosen) > Sent: Monday, July 31, 2006 4:31 PM > To: IETF SIP List > Subject: [Sip] updated acr code draft >=20 > I've submitted a minor update to the ACR code draft. Until it appears, = > you can pick it up at: >=20 > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt >=20 > the changes are: >=20 > * replaced P-Asserted-ID with P-Asserted-Identity >=20 > * added to security considerations section, consideration for=20 > anonymizers in the network. Namely, don't retry request on receipt of > 433 unless explicitly configured to do so by user >=20 >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 03 10:24:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8e5d-0004kK-Of; Thu, 03 Aug 2006 10:22:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8e5c-0004kF-7P for sip@ietf.org; Thu, 03 Aug 2006 10:22:20 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8e5a-0001Eg-N5 for sip@ietf.org; Thu, 03 Aug 2006 10:22:20 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2006 07:22:18 -0700 X-IronPort-AV: i="4.07,208,1151910000"; d="scan'208"; a="333725442:sNHT48190352" 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.20060308/8.12.11) with ESMTP id k73EMICR005824; Thu, 3 Aug 2006 07:22:18 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k73EMHYr019703; Thu, 3 Aug 2006 07:22:17 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 10:22:17 -0400 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 Subject: RE: [Sip] updated acr code draft Date: Thu, 3 Aug 2006 10:22:16 -0400 Message-ID: <47F3B0799A62BB48B096A4DC5BB3B11D01C7051F@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] updated acr code draft Thread-Index: Aca2wQlZzxzX0XT4QIaOaBs1IzqbXQAQ2c2QAAC97SA= From: "Mohammad Al-Taraireh \(maltarai\)" To: "Sanjay Sinha \(sanjsinh\)" , "Jesske, R" , "Jonathan Rosenberg \(jdrosen\)" , X-OriginalArrivalTime: 03 Aug 2006 14:22:17.0398 (UTC) FILETIME=[39342D60:01C6B708] DKIM-Signature: a=rsa-sha1; q=dns; l=4476; t=1154614938; x=1155478938; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=maltarai@cisco.com; z=From:=22Mohammad=20Al-Taraireh=20\(maltarai\)=22=20 |Subject:RE=3A=20[Sip]=20updated=20acr=20code=20draft; X=v=3Dcisco.com=3B=20h=3D7AnlpAKvVe8FqShot/tfaxrRQpU=3D; b=XdeuqM2dEvXxzK2DAl1PFFhmpZBvRgBGLO2hwEKX6iJexSlTkeID7H6L49luH8sNV5yvVXMu Mv682X7Fe1YAqlYKjk+/i1aNuJXPnXaX5kfJW91y9Waq8FNaoxPn+e2a; Authentication-Results: sj-dkim-3.cisco.com; header.From=maltarai@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: "Mohammad Al-Taraireh \(maltarai\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Another case is a early attended transfer. For example the transfer = target will get an INVITE without caller id blocking and then an UPDATE = after the xfer with caller id blocking to change the display. If there = is a policy on the endpoint to reject anonymous calls, what should the=20 do in this case? which the question below "what does 433 mean for mid = call UPDATE or reINVITE?" Thanks, Mo=20 -----Original Message----- From: Sanjay Sinha (sanjsinh)=20 Sent: Thursday, August 03, 2006 9:57 AM To: Jesske, R; Jonathan Rosenberg (jdrosen); sip@ietf.org Subject: RE: [Sip] updated acr code draft Scenario is PSTN-SIP interworking. For some cases, display IE is not = available in SETUP because some TCAP query is required. When the query = is complete, switch sends display IE in a FACILITY message. From header = is mandatory in INVITE, but calling name and number is not. So Invite is = sent without caller-identity which is later updated with an UPDATE/INFO, = when the UA gets FACILITY with display information. Thanks Sanjay.=20 -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net] Sent: Thursday, August 03, 2006 1:52 AM To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen); sip@ietf.org Subject: AW: [Sip] updated acr code draft The ACR service itself reacts only on identities that are put anonymus = by the user or on behalf on the user. So if the restriction is based on other reasons ACR will not terminate = the call. My question to your scenario is in which case an identity is not = available in an INVITE. The From header is an mandatory header so the = >From Header has have an user identity. Or not? The P-Asserted-Identity is set by an trusted network entity that is = aware of the user sending that request. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > Gesendet: Mittwoch, 2. August 2006 17:32 > An: Jonathan Rosenberg (jdrosen); IETF SIP List > Betreff: RE: [Sip] updated acr code draft >=20 >=20 > What about the case in which caller information is not available at=20 > the time INVITE is sent to establish a call, but is available later=20 > and an UPDATE/INFO is sent by UAC to update the caller-id information. > If UAS rejects UPDATE/INFO with 433, what does it mean for the Invite=20 > dialog. > Should that also be terminated as a result of ACR? >=20 > Thanks > Sanjay >=20 > -----Original Message----- > From: Jonathan Rosenberg (jdrosen) > Sent: Monday, July 31, 2006 4:31 PM > To: IETF SIP List > Subject: [Sip] updated acr code draft >=20 > I've submitted a minor update to the ACR code draft. Until it appears, = > you can pick it up at: >=20 > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt >=20 > the changes are: >=20 > * replaced P-Asserted-ID with P-Asserted-Identity >=20 > * added to security considerations section, consideration for=20 > anonymizers in the network. Namely, don't retry request on receipt of > 433 unless explicitly configured to do so by user >=20 >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.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://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 03 10:41:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8eMj-0007iv-7q; Thu, 03 Aug 2006 10:40:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8eMh-0007i0-Np for sip@ietf.org; Thu, 03 Aug 2006 10:39:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8eMg-0001jv-4i for sip@ietf.org; Thu, 03 Aug 2006 10:39:59 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2006 07:39:56 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,208,1151910000"; d="scan'208"; a="34410451:sNHT27714244" 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.20060308/8.12.11) with ESMTP id k73EduNk022608; Thu, 3 Aug 2006 10:39:56 -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.12.10/8.12.6) with ESMTP id k73EdudU015673; Thu, 3 Aug 2006 10:39:56 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 10:39:56 -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 Subject: RE: [Sip] SIP Security mechanism? Date: Thu, 3 Aug 2006 10:39:54 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301C6DAF8@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Security mechanism? Thread-Index: AcazIw5SLpOEQu/PTNaR+5Isznjs8AD5fG+g From: "Michael Hammer \(mhammer\)" To: , "Fries, Steffen" X-OriginalArrivalTime: 03 Aug 2006 14:39:56.0078 (UTC) FILETIME=[B039ECE0:01C6B70A] DKIM-Signature: a=rsa-sha1; q=dns; l=13335; t=1154615996; x=1155479996; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20SIP=20Security=20mechanism? |To:, =20=22Fries, =20Steffen=22=20; X=v=3Dcisco.com=3B=20h=3DI0p3GzFWqht/XmWhcLsxEhFui4c=3D; b=OZLL9NhlPOUgmysPma+nWlwczOZO60VzKNENx87tWo43R+RPSssHCMTuxYEtnIsLhedrp1RD v9OxxxEa8MDTNheiQAOJS4mCX3y5/BoR12iL3eassrHTL3i37hWgGpt7; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank, This is not an accurate depiction of Diffie-Hellman. Use of the terms public key and private key are misleading. Both parties generate a secret, derive a value from that, pass the derived value, then do another operation with the exchanged values to come up with the same *secret* key. A more detailed explanation follows: The Diffie-Hellman algorithm's purpose is to enable two parties to independently generate the same key to secure subsequent messages. The parties exchange values in the clear that are derived from values kept secret by each party. Both parties start off with a prime number Q and A, which is a primitive root of Q. These may be generated by one side and passed to the other in the clear. Each side then chooses a number X, kept private, and calculates Y=3DAX mod Q, then they exchange Y = values. Each party can now generate the key K=3DYX mod Q using their private X = and the other party's Y value. (Party 1: K=3DY2X1 mod Q, Party 2: K=3DY1X2 = mod Q) Both parties have the same key because the two YX values are equivalent to K=3DAX1*X2 mod Q by the rules of modular arithmetic. The strength of the algorithm is derived from the difficulty, when using large prime numbers, to calculate the discrete logarithm of Y to get either X value. The end result is that you have a secure connection to *someone*. It doesn't help you know who that someone is. Usually additional exhanges across that secure channel are used to do authentication. Hope this helps. Mike > -----Original Message----- > From: Frank W. Miller [mailto:fwmiller@cornfed.com]=20 > Sent: Saturday, July 29, 2006 11:24 AM > To: Fries, Steffen > Cc: Cullen Jennings (fluffy); sip@ietf.org > Subject: RE: [Sip] SIP Security mechanism? >=20 >=20 > Actually, I don't think TLS would be required and I don't=20 > think you need to trust the proxies anymore than you do now. =20 > Diffie-Hellman (if I understand it correctly, which is not a=20 > certainty) essentially causes the endpoints to dynamically=20 > generate public keys that have corresponding private keys. =20 > The receiver sends the public key to the sender to be used=20 > for encryption and uses the private key for decryption. This=20 > mechanism would allow for the public keys to be passed in the=20 > clear in the initial exchange and that means it could be used=20 > with any type of transport. >=20 > The proposal has weaknesses (i.e. difficulties with=20 > authentication, MitM attacks), but it does allow for simple=20 > key exchange that doesn't require ANY infrastructure which=20 > should facilitate encryption of bodies if proxies are present=20 > and entire messages if the UAs are B2B. The proposal is=20 > focused mainly on the difficulties associated with key and=20 > certificate management that have been observed operationally.=20 > By eliminating that part of the process, perhaps encryption=20 > would become more pervasive, which would be a good thing IMHO. >=20 > Thanks, > FM >=20 >=20 >=20 > On Wed, 2006-07-26 at 08:47 +0200, Fries, Steffen wrote: > > Hi Frank, > >=20 > > the method you are describing at least requires the usage of TLS to=20 > > protect the key exchange between Alice and Bob. Moreover,=20 > you do need=20 > > to trust the proxies in between, as they have access to the keys=20 > > (assumed you send the key from Alice to Bob in the SDP). You may=20 > > combine the SIP_CERTS approach with=20 > > draft-ono-sipping-smime-keyreuse-01.txt to have one S/MIME=20 > encryption=20 > > based on certificates and use the key-reuse for the rest of the=20 > > session. But as I wrote last time, the draft regarding=20 > key-usage has expired and I'm not sure if it will be updated. > >=20 > > Ciao > > Steffen > >=20 > > > -----Original Message----- > > > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > > > Sent: Saturday, July 22, 2006 3:58 AM > > > To: Cullen Jennings > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] SIP Security mechanism? > > >=20 > > >=20 > > > Thanks for the pointer. I have scanned this draft over. > > >=20 > > > The goal of your draft is similar to what I'm targeting=20 > but slightly=20 > > > different. Please correct me if I am misunderstanding=20 > something. =20 > > > The draft (which is now > > > draft-ietf-sip-certs-01 I believe) has the goal is to=20 > provide a way=20 > > > to make the distribution of certificates more automated=20 > by providing=20 > > > specific infrastructure that is based on simple user=20 > actions. The=20 > > > draft specifies publication and an event package that allows for=20 > > > notification to interested User Agents of certificates. > > >=20 > > > The great benefit to this approach is its preservation of user=20 > > > authentication. > > >=20 > > > My thought was much simpler. Let me drop in a quote from=20 > the ZRTP=20 > > > draft, draft-zimmermann-avt-zrtp-01.txt: > > >=20 > > > ZRTP is key agreement protocol which performs Diffie-Hellman key > > > exchange during call setup in-band in the Real-time Transport > > > Protocol (RTP) [1] media stream which has been=20 > established using=20 > > > some > > > other signaling protocol such as Session Initiation=20 > Protocol (SIP) > > > [11]. This generates a shared secret which is then used to=20 > > > generate > > > keys and salt for a Secure RTP (SRTP) [2] session. > > >=20 > > > Although it uses > > > a public key algorithm, it does not rely on a public key > > > infrastructure (PKI). > > >=20 > > > Were we to put in place some sort of simple transaction that did=20 > > > this key exchange before any other signaling, we could=20 > use the keys=20 > > > to do encryption of the message bodies (similar to what S/MIME is=20 > > > doing) without having to deal with PKI at all. Since the main=20 > > > problem with the use of S/MIME to date has been the certificate=20 > > > management, this approach is also targeting the problem that your=20 > > > draft is. > > >=20 > > > However, there are a couple of differences. First, your draft=20 > > > approach preserves full S/MIME certificate based authentication,=20 > > > this approach would likely not do that, it would be to allow for=20 > > > encryption only. The ZRTP draft proposes prompting the=20 > user with a=20 > > > short authentication string for the media but I don't=20 > know if that=20 > > > would be useful for the signaling. Second, this approach=20 > would be=20 > > > much simpler, likely requiring only a couple of messages=20 > between the=20 > > > UA endpoints. It would not require the centralized=20 > server elements=20 > > > that would be necessary for the PUBLISH/SUBSCRIBE/NOTIFY=20 > components=20 > > > of your draft. > > >=20 > > > Consider the messages used to do key exchange in ZRTP (again from=20 > > > the ZRTP draft): > > >=20 > > > Alice Bob > > > | | > > > | Alice and Bob establish a media session.| > > > | | > > > | RTP | > > > = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > | | > > > | Hello (ver,cid,hash,cipher,pkt,sas,Alice's ZID) F1 > > > |---------------------------------------->| > > > | HelloACK F2 | > > > |<----------------------------------------| > > > | Hello (ver,cid,hash,cipher,pkt,sas,Bob's ZID) F3 > > > |<----------------------------------------| > > > | HelloACK F4 | > > > |---------------------------------------->| > > > | | > > > | Bob acts as the initiator | > > > | | > > > | Commit (Bob's ZID,hash,cipher,pkt,hvi) F5 > > > |<----------------------------------------| > > > | DHPart1=20 > (pvr,rs1IDr,rs2IDr,sigsIDr,srtpsIDr,other_secretIDr) F6 > > > |---------------------------------------->| > > > | DHPart2=20 > (pvi,rs1IDi,rs2IDi,sigsIDi,ssrtpIDi,other_secretIDi) F7 > > > |<----------------------------------------| > > > | | > > > | Alice and Bob generate SRTP session key.| > > > | | > > > | SRTP begins | > > > = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > | | > > > | Confirm1 (plaintext,sasflag,hmac) F8 | > > > |---------------------------------------->| > > > | Confirm2 (plaintext,sasflag,hmac) F9 | > > > |<----------------------------------------| > > > | Confirm2AK F10 | > > > |---------------------------------------->| > > >=20 > > >=20 > > > They are generating keys for each of media streams here, i.e.=20 > > > an inband message exchange is happening in each direction. =20 > > > Something like this could probably be simplified to just two=20 > > > messages for the signaling, something like: > > >=20 > > > Bob Alice > > > | HELLO | > > > |------------------------------->| > > > | 200 OK | > > > |<-------------------------------| > > > | | > > >=20 > > > This example uses a new method I made up called HELLO but=20 > I suppose=20 > > > this could be folded into the INVITE transaction too, using a=20 > > > mechanism similar to the 407. The key that Alice is=20 > supposed to use=20 > > > to encrypt the bodies sent to Bob would be in the HELLO=20 > and the key=20 > > > that Bob is supposed to use encrypt the bodies sent to=20 > Alice would=20 > > > be in the 200 OK. > > >=20 > > > Is this clearer? Does it make sense? Its simpler but the=20 > > > authentication may not be there. That works for the=20 > media because=20 > > > you can possibly recognize someone's voice. In the signaling the=20 > > > authentication thing may be a bigger issue. > > >=20 > > > FM > > >=20 > > >=20 > > > On Fri, 2006-07-21 at 00:17 -0700, Cullen Jennings wrote: > > > > you might want to have a read of > > > draft-ietf-sipping-certs-04 if your > > > > goal is to make sure that users can find the keys of other > > > users for > > > > use with S/MIME > > > >=20 > > > > On Jul 19, 2006, at 12:17 PM, fwmiller@cornfed.com wrote: > > > >=20 > > > > > > > > > > > > > > > I've been reading about the ZRTP lately. I read > > > Henning's comment > > > > > at the IETF meeting about how S/MIME relies on the > > > receiver's public > > > > > key to be available to allow for=20 > encryption/decryption to work. > > > > > > > > > > Why couldnt we put in place a mechanism that did a key > > > exchange for > > > > > SIP signaling similar to whats done in ZRTP (i.e. modified=20 > > > > > Diffie- > > > > > Hellman) prior to any signaling traffic, then use the > > > exchanged keys > > > > > as the basis for S/MIME encryption of the bodies? Or we > > > could even > > > > > get really carried away and use it to do encryption of the=20 > > > > > entire SIP message if the signaling did not traverse proxies? > > > This could > > > > > be useful for encrypting UDP signaling, again if no=20 > proxy were=20 > > > > > involved. > > > > > > > > > > Thoughts? > > > > > FM > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.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=20 > application of=20 > > > > > sip > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.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 > > _______________________________________________ > > Sip mailing list https://www1.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 > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 03 13:44:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8hCs-0002oL-6i; Thu, 03 Aug 2006 13:42:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8hCr-0002n6-5Z for sip@ietf.org; Thu, 03 Aug 2006 13:42:01 -0400 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8hCq-0001fd-Jo for sip@ietf.org; Thu, 03 Aug 2006 13:42:01 -0400 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k73Hflx28865; Thu, 3 Aug 2006 12:41:47 -0500 Date: Thu, 3 Aug 2006 12:41:47 -0500 Message-Id: <200608031741.k73Hflx28865@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: "Michael Hammer (mhammer)" , fwmiller@cornfed.com, "Fries, Steffen" Subject: RE: [Sip] SIP Security mechanism? X-Spam-Score: 0.2 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for clarifying. I am obviously not an expert in DH so this additional description is great. I understood it enough to recognize the underlying semantic which sounds like it is still valid with this clarification in specific terminology. I guess that means my question still stands. Is the use of this technology interesting for use in the encryption of SIP message bodies when SIP messages pass through proxies and could it perhaps be used to encrypt entire messages if the signaling is between UAs directly? This could be a nice mechanism to allow for encryption with UDP transports. The authentication problem remains. IIRC, the ZRTP draft treats this two ways. First, since its targeted at media it assumes that you can do at least some "voice recognition" when you make a voice call. Second, it includes a cheesy little "authentication string" (whatever that is) that can be sent through the secure channel once encryption is in place. I'll admit to not completely understanding how that would be implemented. In any event, I think decoupling authentication from encryption still gives some value. Perhaps I should scratch out a draft outline based on my last email. I've actually looked over the S/MIME section of 3261 hoping to determine how hard it would be to "substitute" the (what I'll call) keys generated by DH for the certificates in S/MIME. I'm still thinking about it. Regards, FM ------------------------------------------------ On Thu, 3 Aug 2006 10:39:54 -0400, "Michael Hammer \(mhammer\)" wrote: > Frank, > > This is not an accurate depiction of Diffie-Hellman. Use of the terms > public key and private key are misleading. Both parties generate a > secret, derive a value from that, pass the derived value, then do > another operation with the exchanged values to come up with the same > *secret* key. A more detailed explanation follows: > > The Diffie-Hellman algorithm's purpose is to enable two parties to > independently generate the same key to secure subsequent messages. The > parties exchange values in the clear that are derived from values kept > secret by each party. Both parties start off with a prime number Q and > A, which is a primitive root of Q. These may be generated by one side > and passed to the other in the clear. Each side then chooses a number > X, kept private, and calculates Y=AX mod Q, then they exchange Y values. > Each party can now generate the key K=YX mod Q using their private X and > the other party's Y value. (Party 1: K=Y2X1 mod Q, Party 2: K=Y1X2 mod > Q) Both parties have the same key because the two YX values are > equivalent to K=AX1*X2 mod Q by the rules of modular arithmetic. The > strength of the algorithm is derived from the difficulty, when using > large prime numbers, to calculate the discrete logarithm of Y to get > either X value. > > The end result is that you have a secure connection to *someone*. It > doesn't help you know who that someone is. Usually additional exhanges > across that secure channel are used to do authentication. Hope this > helps. > > Mike > > > > -----Original Message----- > > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > > Sent: Saturday, July 29, 2006 11:24 AM > > To: Fries, Steffen > > Cc: Cullen Jennings (fluffy); sip@ietf.org > > Subject: RE: [Sip] SIP Security mechanism? > > > > > > Actually, I don't think TLS would be required and I don't > > think you need to trust the proxies anymore than you do now. > > Diffie-Hellman (if I understand it correctly, which is not a > > certainty) essentially causes the endpoints to dynamically > > generate public keys that have corresponding private keys. > > The receiver sends the public key to the sender to be used > > for encryption and uses the private key for decryption. This > > mechanism would allow for the public keys to be passed in the > > clear in the initial exchange and that means it could be used > > with any type of transport. > > > > The proposal has weaknesses (i.e. difficulties with > > authentication, MitM attacks), but it does allow for simple > > key exchange that doesn't require ANY infrastructure which > > should facilitate encryption of bodies if proxies are present > > and entire messages if the UAs are B2B. The proposal is > > focused mainly on the difficulties associated with key and > > certificate management that have been observed operationally. > > By eliminating that part of the process, perhaps encryption > > would become more pervasive, which would be a good thing IMHO. > > > > Thanks, > > FM > > > > > > > > On Wed, 2006-07-26 at 08:47 +0200, Fries, Steffen wrote: > > > Hi Frank, > > > > > > the method you are describing at least requires the usage of TLS to > > > protect the key exchange between Alice and Bob. Moreover, > > you do need > > > to trust the proxies in between, as they have access to the keys > > > (assumed you send the key from Alice to Bob in the SDP). You may > > > combine the SIP_CERTS approach with > > > draft-ono-sipping-smime-keyreuse-01.txt to have one S/MIME > > encryption > > > based on certificates and use the key-reuse for the rest of the > > > session. But as I wrote last time, the draft regarding > > key-usage has expired and I'm not sure if it will be updated. > > > > > > Ciao > > > Steffen > > > > > > > -----Original Message----- > > > > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > > > > Sent: Saturday, July 22, 2006 3:58 AM > > > > To: Cullen Jennings > > > > Cc: sip@ietf.org > > > > Subject: Re: [Sip] SIP Security mechanism? > > > > > > > > > > > > Thanks for the pointer. I have scanned this draft over. > > > > > > > > The goal of your draft is similar to what I'm targeting > > but slightly > > > > different. Please correct me if I am misunderstanding > > something. > > > > The draft (which is now > > > > draft-ietf-sip-certs-01 I believe) has the goal is to > > provide a way > > > > to make the distribution of certificates more automated > > by providing > > > > specific infrastructure that is based on simple user > > actions. The > > > > draft specifies publication and an event package that allows for > > > > notification to interested User Agents of certificates. > > > > > > > > The great benefit to this approach is its preservation of user > > > > authentication. > > > > > > > > My thought was much simpler. Let me drop in a quote from > > the ZRTP > > > > draft, draft-zimmermann-avt-zrtp-01.txt: > > > > > > > > ZRTP is key agreement protocol which performs Diffie-Hellman key > > > > exchange during call setup in-band in the Real-time Transport > > > > Protocol (RTP) [1] media stream which has been > > established using > > > > some > > > > other signaling protocol such as Session Initiation > > Protocol (SIP) > > > > [11]. This generates a shared secret which is then used to > > > > generate > > > > keys and salt for a Secure RTP (SRTP) [2] session. > > > > > > > > Although it uses > > > > a public key algorithm, it does not rely on a public key > > > > infrastructure (PKI). > > > > > > > > Were we to put in place some sort of simple transaction that did > > > > this key exchange before any other signaling, we could > > use the keys > > > > to do encryption of the message bodies (similar to what S/MIME is > > > > doing) without having to deal with PKI at all. Since the main > > > > problem with the use of S/MIME to date has been the certificate > > > > management, this approach is also targeting the problem that your > > > > draft is. > > > > > > > > However, there are a couple of differences. First, your draft > > > > approach preserves full S/MIME certificate based authentication, > > > > this approach would likely not do that, it would be to allow for > > > > encryption only. The ZRTP draft proposes prompting the > > user with a > > > > short authentication string for the media but I don't > > know if that > > > > would be useful for the signaling. Second, this approach > > would be > > > > much simpler, likely requiring only a couple of messages > > between the > > > > UA endpoints. It would not require the centralized > > server elements > > > > that would be necessary for the PUBLISH/SUBSCRIBE/NOTIFY > > components > > > > of your draft. > > > > > > > > Consider the messages used to do key exchange in ZRTP (again from > > > > the ZRTP draft): > > > > > > > > Alice Bob > > > > | | > > > > | Alice and Bob establish a media session.| > > > > | | > > > > | RTP | > > > > |<=======================================>| > > > > | | > > > > | Hello (ver,cid,hash,cipher,pkt,sas,Alice's ZID) F1 > > > > |---------------------------------------->| > > > > | HelloACK F2 | > > > > |<----------------------------------------| > > > > | Hello (ver,cid,hash,cipher,pkt,sas,Bob's ZID) F3 > > > > |<----------------------------------------| > > > > | HelloACK F4 | > > > > |---------------------------------------->| > > > > | | > > > > | Bob acts as the initiator | > > > > | | > > > > | Commit (Bob's ZID,hash,cipher,pkt,hvi) F5 > > > > |<----------------------------------------| > > > > | DHPart1 > > (pvr,rs1IDr,rs2IDr,sigsIDr,srtpsIDr,other_secretIDr) F6 > > > > |---------------------------------------->| > > > > | DHPart2 > > (pvi,rs1IDi,rs2IDi,sigsIDi,ssrtpIDi,other_secretIDi) F7 > > > > |<----------------------------------------| > > > > | | > > > > | Alice and Bob generate SRTP session key.| > > > > | | > > > > | SRTP begins | > > > > |<=======================================>| > > > > | | > > > > | Confirm1 (plaintext,sasflag,hmac) F8 | > > > > |---------------------------------------->| > > > > | Confirm2 (plaintext,sasflag,hmac) F9 | > > > > |<----------------------------------------| > > > > | Confirm2AK F10 | > > > > |---------------------------------------->| > > > > > > > > > > > > They are generating keys for each of media streams here, i.e. > > > > an inband message exchange is happening in each direction. > > > > Something like this could probably be simplified to just two > > > > messages for the signaling, something like: > > > > > > > > Bob Alice > > > > | HELLO | > > > > |------------------------------->| > > > > | 200 OK | > > > > |<-------------------------------| > > > > | | > > > > > > > > This example uses a new method I made up called HELLO but > > I suppose > > > > this could be folded into the INVITE transaction too, using a > > > > mechanism similar to the 407. The key that Alice is > > supposed to use > > > > to encrypt the bodies sent to Bob would be in the HELLO > > and the key > > > > that Bob is supposed to use encrypt the bodies sent to > > Alice would > > > > be in the 200 OK. > > > > > > > > Is this clearer? Does it make sense? Its simpler but the > > > > authentication may not be there. That works for the > > media because > > > > you can possibly recognize someone's voice. In the signaling the > > > > authentication thing may be a bigger issue. > > > > > > > > FM > > > > > > > > > > > > On Fri, 2006-07-21 at 00:17 -0700, Cullen Jennings wrote: > > > > > you might want to have a read of > > > > draft-ietf-sipping-certs-04 if your > > > > > goal is to make sure that users can find the keys of other > > > > users for > > > > > use with S/MIME > > > > > > > > > > On Jul 19, 2006, at 12:17 PM, fwmiller@cornfed.com wrote: > > > > > > > > > > > > > > > > > > > > > > > I've been reading about the ZRTP lately. I read > > > > Henning's comment > > > > > > at the IETF meeting about how S/MIME relies on the > > > > receiver's public > > > > > > key to be available to allow for > > encryption/decryption to work. > > > > > > > > > > > > Why couldnt we put in place a mechanism that did a key > > > > exchange for > > > > > > SIP signaling similar to whats done in ZRTP (i.e. modified > > > > > > Diffie- > > > > > > Hellman) prior to any signaling traffic, then use the > > > > exchanged keys > > > > > > as the basis for S/MIME encryption of the bodies? Or we > > > > could even > > > > > > get really carried away and use it to do encryption of the > > > > > > entire SIP message if the signaling did not traverse proxies? > > > > This could > > > > > > be useful for encrypting UDP signaling, again if no > > proxy were > > > > > > involved. > > > > > > > > > > > > Thoughts? > > > > > > FM > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www1.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://www1.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://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 03 14:30:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8hwK-0001wR-8K; Thu, 03 Aug 2006 14:29:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8hwJ-0001vE-2L for sip@ietf.org; Thu, 03 Aug 2006 14:28:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8hwI-0001Q9-3v for sip@ietf.org; Thu, 03 Aug 2006 14:28:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Aug 2006 11:28:57 -0700 X-IronPort-AV: i="4.07,209,1151910000"; d="scan'208"; a="438559848:sNHT34505556" 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.20060308/8.12.11) with ESMTP id k73ISvvE001293; Thu, 3 Aug 2006 11:28:57 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k73ISumQ015618; Thu, 3 Aug 2006 11:28:57 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 14:28:56 -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 Subject: RE: [Sip] SIP Security mechanism? Date: Thu, 3 Aug 2006 14:28:55 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301C6DBDF@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Security mechanism? Thread-Index: Aca3JCGB71L0Mv54RlCUJInZE/oJGgABXXmg From: "Michael Hammer \(mhammer\)" To: , "Fries, Steffen" X-OriginalArrivalTime: 03 Aug 2006 18:28:56.0642 (UTC) FILETIME=[AE3D9A20:01C6B72A] DKIM-Signature: a=rsa-sha1; q=dns; l=17326; t=1154629737; x=1155493737; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20SIP=20Security=20mechanism?; X=v=3Dcisco.com=3B=20h=3DI0p3GzFWqht/XmWhcLsxEhFui4c=3D; b=cxFpMoIZ5eli9609aZDgqaRmDKoSYLhZbKHoLARHhAqxozSm3PV53C8meVNLAV4I9bnZJDUv /lcJBRbRYXKdd2QuIejYVC/AJ68rPTu3gINYvCmO9IaWi2/8TOsotpg0; Authentication-Results: sj-dkim-4.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank, My post did not address your main question. If I understand your requirements correctly, then yes it could be applied to arrive at a shared key for encryption rather than worrying about key compromise during transmission. Francois Audet and Dan Wing had also written an extensive draft comparing multiple proposed mechanisms for media security and there may be other requirements not met. I seem to remember D-H being in there somewhere: Evaluation of SRTP Keying with SIP: draft-wing-rtpsec-keying-eval-01 Might be worth a look for similar issues. Mike > -----Original Message----- > From: fwmiller@cornfed.com [mailto:fwmiller@cornfed.com]=20 > Sent: Thursday, August 03, 2006 1:42 PM > To: Michael Hammer (mhammer); fwmiller@cornfed.com; Fries, Steffen > Cc: Cullen Jennings (fluffy); sip@ietf.org > Subject: RE: [Sip] SIP Security mechanism? >=20 >=20 > Thanks for clarifying. I am obviously not an expert in DH so=20 > this additional description is great. I understood it enough=20 > to recognize the underlying semantic which sounds like it is=20 > still valid with this clarification in specific terminology. =20 > I guess that means my question still stands. Is the use of=20 > this technology interesting for use in the encryption of SIP=20 > message bodies when SIP messages pass through proxies and=20 > could it perhaps be used to encrypt entire messages if the=20 > signaling is between UAs directly? This could be a nice=20 > mechanism to allow for encryption with UDP transports. >=20 > The authentication problem remains. IIRC, the ZRTP draft=20 > treats this two ways. First, since its targeted at media it=20 > assumes that you can do at least some "voice recognition"=20 > when you make a voice call. Second, it includes a cheesy=20 > little "authentication string" (whatever that is) that can be=20 > sent through the secure channel once encryption is in place. =20 > I'll admit to not completely understanding how that would be=20 > implemented. In any event, I think decoupling authentication=20 > from encryption still gives some value. >=20 > Perhaps I should scratch out a draft outline based on my last=20 > email. I've actually looked over the S/MIME section of 3261=20 > hoping to determine how hard it would be to "substitute" the=20 > (what I'll call) keys generated by DH for the certificates in=20 > S/MIME. I'm still thinking about it. >=20 > Regards, > FM >=20 >=20 >=20 > ------------------------------------------------ > On Thu, 3 Aug 2006 10:39:54 -0400, "Michael Hammer=20 > \(mhammer\)" wrote: >=20 > > Frank, > >=20 > > This is not an accurate depiction of Diffie-Hellman. Use=20 > of the terms=20 > > public key and private key are misleading. Both parties generate a=20 > > secret, derive a value from that, pass the derived value, then do=20 > > another operation with the exchanged values to come up with the same > > *secret* key. A more detailed explanation follows: > >=20 > > The Diffie-Hellman algorithm's purpose is to enable two parties to=20 > > independently generate the same key to secure subsequent messages. =20 > > The parties exchange values in the clear that are derived=20 > from values=20 > > kept secret by each party. Both parties start off with a=20 > prime number=20 > > Q and A, which is a primitive root of Q. These may be generated by=20 > > one side and passed to the other in the clear. Each side=20 > then chooses=20 > > a number X, kept private, and calculates Y=3DAX mod Q, then=20 > they exchange Y values. > > Each party can now generate the key K=3DYX mod Q using their=20 > private X=20 > > and the other party's Y value. (Party 1: K=3DY2X1 mod Q, Party 2:=20 > > K=3DY1X2 mod > > Q) Both parties have the same key because the two YX values are=20 > > equivalent to K=3DAX1*X2 mod Q by the rules of modular=20 > arithmetic. The=20 > > strength of the algorithm is derived from the difficulty,=20 > when using=20 > > large prime numbers, to calculate the discrete logarithm of=20 > Y to get=20 > > either X value. > >=20 > > The end result is that you have a secure connection to=20 > *someone*. It=20 > > doesn't help you know who that someone is. Usually additional=20 > > exhanges across that secure channel are used to do authentication. =20 > > Hope this helps. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > > > Sent: Saturday, July 29, 2006 11:24 AM > > > To: Fries, Steffen > > > Cc: Cullen Jennings (fluffy); sip@ietf.org > > > Subject: RE: [Sip] SIP Security mechanism? > > >=20 > > >=20 > > > Actually, I don't think TLS would be required and I don't=20 > think you=20 > > > need to trust the proxies anymore than you do now. > > > Diffie-Hellman (if I understand it correctly, which is not a > > > certainty) essentially causes the endpoints to=20 > dynamically generate=20 > > > public keys that have corresponding private keys. > > > The receiver sends the public key to the sender to be used for=20 > > > encryption and uses the private key for decryption. This=20 > mechanism=20 > > > would allow for the public keys to be passed in the clear in the=20 > > > initial exchange and that means it could be used with any type of=20 > > > transport. > > >=20 > > > The proposal has weaknesses (i.e. difficulties with=20 > authentication,=20 > > > MitM attacks), but it does allow for simple key exchange that=20 > > > doesn't require ANY infrastructure which should facilitate=20 > > > encryption of bodies if proxies are present and entire=20 > messages if=20 > > > the UAs are B2B. The proposal is focused mainly on the=20 > difficulties=20 > > > associated with key and certificate management that have been=20 > > > observed operationally. > > > By eliminating that part of the process, perhaps=20 > encryption would=20 > > > become more pervasive, which would be a good thing IMHO. > > >=20 > > > Thanks, > > > FM > > >=20 > > >=20 > > >=20 > > > On Wed, 2006-07-26 at 08:47 +0200, Fries, Steffen wrote: > > > > Hi Frank, > > > >=20 > > > > the method you are describing at least requires the=20 > usage of TLS=20 > > > > to protect the key exchange between Alice and Bob. Moreover, > > > you do need > > > > to trust the proxies in between, as they have access to=20 > the keys=20 > > > > (assumed you send the key from Alice to Bob in the=20 > SDP). You may=20 > > > > combine the SIP_CERTS approach with=20 > > > > draft-ono-sipping-smime-keyreuse-01.txt to have one S/MIME > > > encryption > > > > based on certificates and use the key-reuse for the rest of the=20 > > > > session. But as I wrote last time, the draft regarding > > > key-usage has expired and I'm not sure if it will be updated. > > > >=20 > > > > Ciao > > > > Steffen > > > >=20 > > > > > -----Original Message----- > > > > > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > > > > > Sent: Saturday, July 22, 2006 3:58 AM > > > > > To: Cullen Jennings > > > > > Cc: sip@ietf.org > > > > > Subject: Re: [Sip] SIP Security mechanism? > > > > >=20 > > > > >=20 > > > > > Thanks for the pointer. I have scanned this draft over. > > > > >=20 > > > > > The goal of your draft is similar to what I'm targeting > > > but slightly > > > > > different. Please correct me if I am misunderstanding > > > something. =20 > > > > > The draft (which is now > > > > > draft-ietf-sip-certs-01 I believe) has the goal is to > > > provide a way > > > > > to make the distribution of certificates more automated > > > by providing > > > > > specific infrastructure that is based on simple user > > > actions. The > > > > > draft specifies publication and an event package that=20 > allows for=20 > > > > > notification to interested User Agents of certificates. > > > > >=20 > > > > > The great benefit to this approach is its=20 > preservation of user=20 > > > > > authentication. > > > > >=20 > > > > > My thought was much simpler. Let me drop in a quote from > > > the ZRTP > > > > > draft, draft-zimmermann-avt-zrtp-01.txt: > > > > >=20 > > > > > ZRTP is key agreement protocol which performs=20 > Diffie-Hellman key > > > > > exchange during call setup in-band in the=20 > Real-time Transport > > > > > Protocol (RTP) [1] media stream which has been > > > established using > > > > > some > > > > > other signaling protocol such as Session Initiation > > > Protocol (SIP) > > > > > [11]. This generates a shared secret which is=20 > then used to=20 > > > > > generate > > > > > keys and salt for a Secure RTP (SRTP) [2] session. > > > > >=20 > > > > > Although it uses > > > > > a public key algorithm, it does not rely on a public key > > > > > infrastructure (PKI). > > > > >=20 > > > > > Were we to put in place some sort of simple=20 > transaction that did=20 > > > > > this key exchange before any other signaling, we could > > > use the keys > > > > > to do encryption of the message bodies (similar to=20 > what S/MIME=20 > > > > > is > > > > > doing) without having to deal with PKI at all. Since=20 > the main=20 > > > > > problem with the use of S/MIME to date has been the=20 > certificate=20 > > > > > management, this approach is also targeting the problem that=20 > > > > > your draft is. > > > > >=20 > > > > > However, there are a couple of differences. First,=20 > your draft=20 > > > > > approach preserves full S/MIME certificate based=20 > authentication,=20 > > > > > this approach would likely not do that, it would be=20 > to allow for=20 > > > > > encryption only. The ZRTP draft proposes prompting the > > > user with a > > > > > short authentication string for the media but I don't > > > know if that > > > > > would be useful for the signaling. Second, this approach > > > would be > > > > > much simpler, likely requiring only a couple of messages > > > between the > > > > > UA endpoints. It would not require the centralized > > > server elements > > > > > that would be necessary for the PUBLISH/SUBSCRIBE/NOTIFY > > > components > > > > > of your draft. > > > > >=20 > > > > > Consider the messages used to do key exchange in ZRTP (again=20 > > > > > from the ZRTP draft): > > > > >=20 > > > > > Alice Bob > > > > > | | > > > > > | Alice and Bob establish a media session.| > > > > > | | > > > > > | RTP | > > > > > = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > > > | | > > > > > | Hello (ver,cid,hash,cipher,pkt,sas,Alice's ZID) F1 > > > > > |---------------------------------------->| > > > > > | HelloACK F2 | > > > > > |<----------------------------------------| > > > > > | Hello (ver,cid,hash,cipher,pkt,sas,Bob's ZID) F3 > > > > > |<----------------------------------------| > > > > > | HelloACK F4 | > > > > > |---------------------------------------->| > > > > > | | > > > > > | Bob acts as the initiator | > > > > > | | > > > > > | Commit (Bob's ZID,hash,cipher,pkt,hvi) F5 > > > > > |<----------------------------------------| > > > > > | DHPart1 > > > (pvr,rs1IDr,rs2IDr,sigsIDr,srtpsIDr,other_secretIDr) F6 > > > > > |---------------------------------------->| > > > > > | DHPart2 > > > (pvi,rs1IDi,rs2IDi,sigsIDi,ssrtpIDi,other_secretIDi) F7 > > > > > |<----------------------------------------| > > > > > | | > > > > > | Alice and Bob generate SRTP session key.| > > > > > | | > > > > > | SRTP begins | > > > > > = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > > > > | | > > > > > | Confirm1 (plaintext,sasflag,hmac) F8 | > > > > > |---------------------------------------->| > > > > > | Confirm2 (plaintext,sasflag,hmac) F9 | > > > > > |<----------------------------------------| > > > > > | Confirm2AK F10 | > > > > > |---------------------------------------->| > > > > >=20 > > > > >=20 > > > > > They are generating keys for each of media streams here, i.e.=20 > > > > > an inband message exchange is happening in each direction. =20 > > > > > Something like this could probably be simplified to just two=20 > > > > > messages for the signaling, something like: > > > > >=20 > > > > > Bob Alice > > > > > | HELLO | > > > > > |------------------------------->| > > > > > | 200 OK | > > > > > |<-------------------------------| > > > > > | | > > > > >=20 > > > > > This example uses a new method I made up called HELLO but > > > I suppose > > > > > this could be folded into the INVITE transaction too, using a=20 > > > > > mechanism similar to the 407. The key that Alice is > > > supposed to use > > > > > to encrypt the bodies sent to Bob would be in the HELLO > > > and the key > > > > > that Bob is supposed to use encrypt the bodies sent to > > > Alice would > > > > > be in the 200 OK. > > > > >=20 > > > > > Is this clearer? Does it make sense? Its simpler but the=20 > > > > > authentication may not be there. That works for the > > > media because > > > > > you can possibly recognize someone's voice. In the signaling=20 > > > > > the authentication thing may be a bigger issue. > > > > >=20 > > > > > FM > > > > >=20 > > > > >=20 > > > > > On Fri, 2006-07-21 at 00:17 -0700, Cullen Jennings wrote: > > > > > > you might want to have a read of > > > > > draft-ietf-sipping-certs-04 if your > > > > > > goal is to make sure that users can find the keys of other > > > > > users for > > > > > > use with S/MIME > > > > > >=20 > > > > > > On Jul 19, 2006, at 12:17 PM, fwmiller@cornfed.com wrote: > > > > > >=20 > > > > > > > > > > > > > > > > > > > > > I've been reading about the ZRTP lately. I read > > > > > Henning's comment > > > > > > > at the IETF meeting about how S/MIME relies on the > > > > > receiver's public > > > > > > > key to be available to allow for > > > encryption/decryption to work. > > > > > > > > > > > > > > Why couldnt we put in place a mechanism that did a key > > > > > exchange for > > > > > > > SIP signaling similar to whats done in ZRTP (i.e. modified > > > > > > > Diffie- > > > > > > > Hellman) prior to any signaling traffic, then use the > > > > > exchanged keys > > > > > > > as the basis for S/MIME encryption of the bodies? Or we > > > > > could even > > > > > > > get really carried away and use it to do=20 > encryption of the=20 > > > > > > > entire SIP message if the signaling did not=20 > traverse proxies? > > > > > This could > > > > > > > be useful for encrypting UDP signaling, again if no > > > proxy were > > > > > > > involved. > > > > > > > > > > > > > > Thoughts? > > > > > > > FM > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Sip mailing list =20 > https://www1.ietf.org/mailman/listinfo/sip > > > > > > > This list is for NEW development of the core SIP Protocol=20 > > > > > > > Use sip-implementors@cs.columbia.edu for questions on=20 > > > > > > > current sip Use sipping@ietf.org for new=20 > developments on the > > > application of > > > > > > > sip > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.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=20 > application of=20 > > > > > sip > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.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 > > > _______________________________________________ > > > Sip mailing list https://www1.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 >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 03 14:55:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8iKB-00080U-G5; Thu, 03 Aug 2006 14:53:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8iKA-0007zT-8E for sip@ietf.org; Thu, 03 Aug 2006 14:53:38 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8iK8-0006k1-V4 for sip@ietf.org; Thu, 03 Aug 2006 14:53:37 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A6350684; Thu, 03 Aug 2006 14:53:41 -0400 From: "Hadriel Kaplan" To: Subject: RE: [Sip] SIP Security mechanism? Date: Thu, 3 Aug 2006 14:53:30 -0400 Message-ID: <045401c6b72e$1d9aca20$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca3JJTP7OrVcvEoSBisgfh7vUXQFgAAhZSw In-Reply-To: <200608031741.k73Hflx28865@smapp01.siteprotect.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Frank, I'm not sure what the point of it would be. Authentication (and non-repudiation) is the really hard part, and the prize. ZRTP ultimately relies on the user reading out the SAS, or else a MiTM can do b2b-zrtp and no one would be the wiser. (it would be quite expensive though) Voice recognition is meaningless if all I want to do is monitor, and people presumably call strangers a lot (like their bank). The same would be true of your proposal. There is nothing authenticating the encryptor/decryptor is who she claims to be. That's the value of certs. (and they freshen your breath) I think you said the benefit of this is "perhaps encryption would become more pervasive". TLS provides you that (and more), yet it's not pervasive. It's not end-2-end, but then neither is your mechanism ultimately. You also said "you don't need to trust the proxies anymore than you do now". I actually agree, in that I think you have to trust your proxies a lot now. Ironically, it's actually the proxies who don't fully trust you. ;) But I assume you meant you don't have to trust them, and I don't think that's true - because they would be the perfect MiTM against your mechanism. -hadriel > -----Original Message----- > From: fwmiller@cornfed.com [mailto:fwmiller@cornfed.com] > Sent: Thursday, August 03, 2006 1:42 PM > To: Michael Hammer (mhammer); fwmiller@cornfed.com; Fries, Steffen > Cc: Cullen Jennings (fluffy); sip@ietf.org > Subject: RE: [Sip] SIP Security mechanism? > > > Thanks for clarifying. I am obviously not an expert in DH so this > additional description is great. I understood it enough to recognize the > underlying semantic which sounds like it is still valid with this > clarification in specific terminology. I guess that means my question > still stands. Is the use of this technology interesting for use in the > encryption of SIP message bodies when SIP messages pass through proxies > and could it perhaps be used to encrypt entire messages if the signaling > is between UAs directly? This could be a nice mechanism to allow for > encryption with UDP transports. > > The authentication problem remains. IIRC, the ZRTP draft treats this two > ways. First, since its targeted at media it assumes that you can do at > least some "voice recognition" when you make a voice call. Second, it > includes a cheesy little "authentication string" (whatever that is) that > can be sent through the secure channel once encryption is in place. I'll > admit to not completely understanding how that would be implemented. In > any event, I think decoupling authentication from encryption still gives > some value. > > Perhaps I should scratch out a draft outline based on my last email. I've > actually looked over the S/MIME section of 3261 hoping to determine how > hard it would be to "substitute" the (what I'll call) keys generated by DH > for the certificates in S/MIME. I'm still thinking about it. > > Regards, > FM > > > > ------------------------------------------------ > On Thu, 3 Aug 2006 10:39:54 -0400, "Michael Hammer \(mhammer\)" > wrote: > > > Frank, > > > > This is not an accurate depiction of Diffie-Hellman. Use of the terms > > public key and private key are misleading. Both parties generate a > > secret, derive a value from that, pass the derived value, then do > > another operation with the exchanged values to come up with the same > > *secret* key. A more detailed explanation follows: > > > > The Diffie-Hellman algorithm's purpose is to enable two parties to > > independently generate the same key to secure subsequent messages. The > > parties exchange values in the clear that are derived from values kept > > secret by each party. Both parties start off with a prime number Q and > > A, which is a primitive root of Q. These may be generated by one side > > and passed to the other in the clear. Each side then chooses a number > > X, kept private, and calculates Y=AX mod Q, then they exchange Y values. > > Each party can now generate the key K=YX mod Q using their private X and > > the other party's Y value. (Party 1: K=Y2X1 mod Q, Party 2: K=Y1X2 mod > > Q) Both parties have the same key because the two YX values are > > equivalent to K=AX1*X2 mod Q by the rules of modular arithmetic. The > > strength of the algorithm is derived from the difficulty, when using > > large prime numbers, to calculate the discrete logarithm of Y to get > > either X value. > > > > The end result is that you have a secure connection to *someone*. It > > doesn't help you know who that someone is. Usually additional exhanges > > across that secure channel are used to do authentication. Hope this > > helps. > > > > Mike > > > > > > > -----Original Message----- > > > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > > > Sent: Saturday, July 29, 2006 11:24 AM > > > To: Fries, Steffen > > > Cc: Cullen Jennings (fluffy); sip@ietf.org > > > Subject: RE: [Sip] SIP Security mechanism? > > > > > > > > > Actually, I don't think TLS would be required and I don't > > > think you need to trust the proxies anymore than you do now. > > > Diffie-Hellman (if I understand it correctly, which is not a > > > certainty) essentially causes the endpoints to dynamically > > > generate public keys that have corresponding private keys. > > > The receiver sends the public key to the sender to be used > > > for encryption and uses the private key for decryption. This > > > mechanism would allow for the public keys to be passed in the > > > clear in the initial exchange and that means it could be used > > > with any type of transport. > > > > > > The proposal has weaknesses (i.e. difficulties with > > > authentication, MitM attacks), but it does allow for simple > > > key exchange that doesn't require ANY infrastructure which > > > should facilitate encryption of bodies if proxies are present > > > and entire messages if the UAs are B2B. The proposal is > > > focused mainly on the difficulties associated with key and > > > certificate management that have been observed operationally. > > > By eliminating that part of the process, perhaps encryption > > > would become more pervasive, which would be a good thing IMHO. > > > > > > Thanks, > > > FM > > > > > > > > > > > > On Wed, 2006-07-26 at 08:47 +0200, Fries, Steffen wrote: > > > > Hi Frank, > > > > > > > > the method you are describing at least requires the usage of TLS to > > > > protect the key exchange between Alice and Bob. Moreover, > > > you do need > > > > to trust the proxies in between, as they have access to the keys > > > > (assumed you send the key from Alice to Bob in the SDP). You may > > > > combine the SIP_CERTS approach with > > > > draft-ono-sipping-smime-keyreuse-01.txt to have one S/MIME > > > encryption > > > > based on certificates and use the key-reuse for the rest of the > > > > session. But as I wrote last time, the draft regarding > > > key-usage has expired and I'm not sure if it will be updated. > > > > > > > > Ciao > > > > Steffen > > > > > > > > > -----Original Message----- > > > > > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > > > > > Sent: Saturday, July 22, 2006 3:58 AM > > > > > To: Cullen Jennings > > > > > Cc: sip@ietf.org > > > > > Subject: Re: [Sip] SIP Security mechanism? > > > > > > > > > > > > > > > Thanks for the pointer. I have scanned this draft over. > > > > > > > > > > The goal of your draft is similar to what I'm targeting > > > but slightly > > > > > different. Please correct me if I am misunderstanding > > > something. > > > > > The draft (which is now > > > > > draft-ietf-sip-certs-01 I believe) has the goal is to > > > provide a way > > > > > to make the distribution of certificates more automated > > > by providing > > > > > specific infrastructure that is based on simple user > > > actions. The > > > > > draft specifies publication and an event package that allows for > > > > > notification to interested User Agents of certificates. > > > > > > > > > > The great benefit to this approach is its preservation of user > > > > > authentication. > > > > > > > > > > My thought was much simpler. Let me drop in a quote from > > > the ZRTP > > > > > draft, draft-zimmermann-avt-zrtp-01.txt: > > > > > > > > > > ZRTP is key agreement protocol which performs Diffie-Hellman key > > > > > exchange during call setup in-band in the Real-time Transport > > > > > Protocol (RTP) [1] media stream which has been > > > established using > > > > > some > > > > > other signaling protocol such as Session Initiation > > > Protocol (SIP) > > > > > [11]. This generates a shared secret which is then used to > > > > > generate > > > > > keys and salt for a Secure RTP (SRTP) [2] session. > > > > > > > > > > Although it uses > > > > > a public key algorithm, it does not rely on a public key > > > > > infrastructure (PKI). > > > > > > > > > > Were we to put in place some sort of simple transaction that did > > > > > this key exchange before any other signaling, we could > > > use the keys > > > > > to do encryption of the message bodies (similar to what S/MIME is > > > > > doing) without having to deal with PKI at all. Since the main > > > > > problem with the use of S/MIME to date has been the certificate > > > > > management, this approach is also targeting the problem that your > > > > > draft is. > > > > > > > > > > However, there are a couple of differences. First, your draft > > > > > approach preserves full S/MIME certificate based authentication, > > > > > this approach would likely not do that, it would be to allow for > > > > > encryption only. The ZRTP draft proposes prompting the > > > user with a > > > > > short authentication string for the media but I don't > > > know if that > > > > > would be useful for the signaling. Second, this approach > > > would be > > > > > much simpler, likely requiring only a couple of messages > > > between the > > > > > UA endpoints. It would not require the centralized > > > server elements > > > > > that would be necessary for the PUBLISH/SUBSCRIBE/NOTIFY > > > components > > > > > of your draft. > > > > > > > > > > Consider the messages used to do key exchange in ZRTP (again from > > > > > the ZRTP draft): > > > > > > > > > > Alice Bob > > > > > | | > > > > > | Alice and Bob establish a media session.| > > > > > | | > > > > > | RTP | > > > > > |<=======================================>| > > > > > | | > > > > > | Hello (ver,cid,hash,cipher,pkt,sas,Alice's ZID) F1 > > > > > |---------------------------------------->| > > > > > | HelloACK F2 | > > > > > |<----------------------------------------| > > > > > | Hello (ver,cid,hash,cipher,pkt,sas,Bob's ZID) F3 > > > > > |<----------------------------------------| > > > > > | HelloACK F4 | > > > > > |---------------------------------------->| > > > > > | | > > > > > | Bob acts as the initiator | > > > > > | | > > > > > | Commit (Bob's ZID,hash,cipher,pkt,hvi) F5 > > > > > |<----------------------------------------| > > > > > | DHPart1 > > > (pvr,rs1IDr,rs2IDr,sigsIDr,srtpsIDr,other_secretIDr) F6 > > > > > |---------------------------------------->| > > > > > | DHPart2 > > > (pvi,rs1IDi,rs2IDi,sigsIDi,ssrtpIDi,other_secretIDi) F7 > > > > > |<----------------------------------------| > > > > > | | > > > > > | Alice and Bob generate SRTP session key.| > > > > > | | > > > > > | SRTP begins | > > > > > |<=======================================>| > > > > > | | > > > > > | Confirm1 (plaintext,sasflag,hmac) F8 | > > > > > |---------------------------------------->| > > > > > | Confirm2 (plaintext,sasflag,hmac) F9 | > > > > > |<----------------------------------------| > > > > > | Confirm2AK F10 | > > > > > |---------------------------------------->| > > > > > > > > > > > > > > > They are generating keys for each of media streams here, i.e. > > > > > an inband message exchange is happening in each direction. > > > > > Something like this could probably be simplified to just two > > > > > messages for the signaling, something like: > > > > > > > > > > Bob Alice > > > > > | HELLO | > > > > > |------------------------------->| > > > > > | 200 OK | > > > > > |<-------------------------------| > > > > > | | > > > > > > > > > > This example uses a new method I made up called HELLO but > > > I suppose > > > > > this could be folded into the INVITE transaction too, using a > > > > > mechanism similar to the 407. The key that Alice is > > > supposed to use > > > > > to encrypt the bodies sent to Bob would be in the HELLO > > > and the key > > > > > that Bob is supposed to use encrypt the bodies sent to > > > Alice would > > > > > be in the 200 OK. > > > > > > > > > > Is this clearer? Does it make sense? Its simpler but the > > > > > authentication may not be there. That works for the > > > media because > > > > > you can possibly recognize someone's voice. In the signaling the > > > > > authentication thing may be a bigger issue. > > > > > > > > > > FM > > > > > > > > > > > > > > > On Fri, 2006-07-21 at 00:17 -0700, Cullen Jennings wrote: > > > > > > you might want to have a read of > > > > > draft-ietf-sipping-certs-04 if your > > > > > > goal is to make sure that users can find the keys of other > > > > > users for > > > > > > use with S/MIME > > > > > > > > > > > > On Jul 19, 2006, at 12:17 PM, fwmiller@cornfed.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > I've been reading about the ZRTP lately. I read > > > > > Henning's comment > > > > > > > at the IETF meeting about how S/MIME relies on the > > > > > receiver's public > > > > > > > key to be available to allow for > > > encryption/decryption to work. > > > > > > > > > > > > > > Why couldnt we put in place a mechanism that did a key > > > > > exchange for > > > > > > > SIP signaling similar to whats done in ZRTP (i.e. modified > > > > > > > Diffie- > > > > > > > Hellman) prior to any signaling traffic, then use the > > > > > exchanged keys > > > > > > > as the basis for S/MIME encryption of the bodies? Or we > > > > > could even > > > > > > > get really carried away and use it to do encryption of the > > > > > > > entire SIP message if the signaling did not traverse proxies? > > > > > This could > > > > > > > be useful for encrypting UDP signaling, again if no > > > proxy were > > > > > > > involved. > > > > > > > > > > > > > > Thoughts? > > > > > > > FM > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Sip mailing list https://www1.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://www1.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://www1.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://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 03 19:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8mDQ-0004tA-Oe; Thu, 03 Aug 2006 19:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8mDP-0004t4-KB for sip@ietf.org; Thu, 03 Aug 2006 19:02:55 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8mDN-0002vm-B1 for sip@ietf.org; Thu, 03 Aug 2006 19:02:55 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k73N2N928642; Thu, 3 Aug 2006 19:02:24 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-gruu-10.txt Date: Thu, 3 Aug 2006 18:02:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0BFA2E24@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-gruu-10.txt Thread-Index: Aca1thmI5/uL7OYDRFCKIserid3ELgA44R2A From: "Francois Audet" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, I'm having some problem reconciling parts of gruu-10 with RFC 3261. (This problem is not gruu-specific, it also applies to the sips guidelines draft). In section 7.1.2 of gruu-10: A registrar MUST create both the SIP and SIPS versions of the GRUU, such that if the GRUU exists, both URI exist. ...and later in 7.1.2.1 of gruu-10: If the To header field in the REGISTER request contains a SIP URI, the SIP version of the GRUU is returned. If the To header field in the REGISTER request contains a SIPS URI, the SIPS version of the GRUU is returned. However, in RFC 3261/19.14: Some operations in this specification require determining whether two SIP or SIPS URIs are equivalent. In this specification, registrars need to compare bindings in Contact URIs in REGISTER requests (see Section 10.3.). SIP and SIPS URIs are compared for equality according to the following rules: o A SIP and SIPS URI are never equivalent. It's not clear to me what this all means... Are we saying that when we register, it really doesn't matter if the AOR, and Contact (and GRUU) are SIP or SIP because both will end up being=20 "created"? The distinction between the two in registration would therefore be purely mechanical (i.e., if AOR is SIP, Contact/GRUU is SIP, and if=20 AOR is SIPS, Contact/GRUU is SIPs)? So SIPS and SIP are somehow synchronized bingings, but are "not=20 equivalent" (they seem pretty "equivalent" to me...). This is quite confusing... Can you clarify what you think it means? _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 03 20:56:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8nxo-0006Xv-MC; Thu, 03 Aug 2006 20:54:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8nxn-0006Xo-DN for sip@ietf.org; Thu, 03 Aug 2006 20:54:55 -0400 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8nxm-0000Pc-4P for sip@ietf.org; Thu, 03 Aug 2006 20:54:55 -0400 Received: from dimension.cornfed.com (pool-141-157-99-51.balt.east.verizon.net [141.157.99.51]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k740sq528089; Thu, 3 Aug 2006 19:54:52 -0500 Subject: RE: [Sip] SIP Security mechanism? From: "Frank W. Miller" To: Hadriel Kaplan In-Reply-To: <045401c6b72e$1d9aca20$6601a8c0@acmepacket.com> References: <045401c6b72e$1d9aca20$6601a8c0@acmepacket.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Thu, 03 Aug 2006 20:54:07 -0400 Message-Id: <1154652847.2521.30.camel@dimension.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Thu, 2006-08-03 at 14:53 -0400, Hadriel Kaplan wrote: > Hi Frank, > I'm not sure what the point of it would be. > Authentication (and non-repudiation) is the really hard part, and the prize. > Agreed, but end-to-end encryption of the bodies is also hard given the basic architecture of SIP and valuable. S/MIME does that job but there is the problem of managing certs (spearmint for me thanks). This proposal is basically laser focused on providing an alternative to S/MIME that doesn't require central cert/key management, nothing more. It gives up on S/MIME centralized style authentication to do that. That may or may not be interesting. > I think you said the benefit of this is "perhaps encryption would become > more pervasive". TLS provides you that (and more), yet it's not pervasive. > It's not end-2-end, but then neither is your mechanism ultimately. > This proposal could be made end-to-end if some form of authentication were built on top of it. That cannot be said of TLS unless S/MIME or something like this is used in conjunction with it. > You also said "you don't need to trust the proxies anymore than you do now". > I actually agree, in that I think you have to trust your proxies a lot now. > Ironically, it's actually the proxies who don't fully trust you. ;) > > But I assume you meant you don't have to trust them, and I don't think > that's true - because they would be the perfect MiTM against your mechanism. > All true. However, your statement is not an implication. Just because the proxies are perfect MitM attackers for lots of things including this proposal, doesn't mean that that type of attack cannot be defeated if this type of encryption is used. Again, were some end-to-end authentication protocol put in place above this type of encryption, it would solve this problem. S/MIME solves that with centralized cert management but thats not the only way to do authentication. Your discussion is actually crystallizing the thought that perhaps encryption and authentication should be separated architecturally. This would allow for various types of encryption and various types of authentication to be used as required for a given application. This would also allow for situations where authentication is not required but encryption is needed to be implemented separately from those situations that require both. I can think of situations where encryption with essentially implicit authentication are possible. Consider a military wireless network for example. In such a case, the underlying signal in space provides implicit authentication but there can never be enough layers of encryption. One might argue that if you're going to go to the trouble to encrypt, why not do authentication? I think the problem is just what we've seen, managing central repositories of cert information is hard in practice. Hope I'm not rambling on too much now... FM _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 03 20:58:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8o00-0007hN-C4; Thu, 03 Aug 2006 20:57:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8nzz-0007hF-76 for sip@ietf.org; Thu, 03 Aug 2006 20:57:11 -0400 Received: from irvmail2.verizon.com ([192.76.80.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8nzx-00011k-UH for sip@ietf.org; Thu, 03 Aug 2006 20:57:11 -0400 Received: from smtpftw.verizon.com (smtpftw.verizon.com [138.83.130.53]) by irvmail2.verizon.com (8.13.3/8.13.3) with ESMTP id k740vKk9005626 for ; Thu, 3 Aug 2006 19:57:25 -0500 (EST) Received: from ftwintrmemf2.verizon.com (ftwintrmemf2.verizon.com [138.83.131.184]) by smtpftw.verizon.com (8.13.3/8.13.3) with ESMTP id k740v1eF015443 for ; Thu, 3 Aug 2006 19:57:01 -0500 (EST) Received: from coregate2.verizon.com (unknown [138.83.34.48]) by ftwintrmemf2.verizon.com (Symantec Mail Security) with ESMTP id 63828444013 for ; Thu, 3 Aug 2006 20:57:01 -0400 (EDT) Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate2.verizon.com (8.13.3/8.13.3) with ESMTP id k740v0uO026806 for ; Thu, 3 Aug 2006 19:57:01 -0500 (CDT) From: pablo.smiraglia@verizon.com To: sip@ietf.org Message-ID: Date: Thu, 3 Aug 2006 20:56:58 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.5.4HF453 | August 4, 2005) at 08/03/2006 19:57:00 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] Out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I will be out of the office starting 08/03/2006 and will not return until 08/07/2006. I'll be out of the office with no access to email or vmail until 08/07. I'll reply to your message as soon as I can. Best Regards, Pablo Smiraglia _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 00:15:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8r3w-0003yn-Tt; Fri, 04 Aug 2006 00:13:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8r1H-0002kj-Gx for sip@ietf.org; Fri, 04 Aug 2006 00:10:43 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8qpt-0001ib-5s for sip@ietf.org; Thu, 03 Aug 2006 23:58:57 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k743wri02133 for ; Thu, 3 Aug 2006 23:58:53 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Aug 2006 22:58:51 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DA18D8A@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ciphersuites in SIP thread-index: Aca3ekue3KK372lrTKeGuUwdO73mXg== From: "Samir Srivastava" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Subject: [Sip] Ciphersuites in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0050730388==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0050730388== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B77A.4CACEEF9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6B77A.4CACEEF9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1) It was mentioned in the last meeting that Proxies are trusted for the other tasks. So they should be trusted for the cipher-suite also. And we need more stark requirement to justify it. =20 =20 Proxies based on the policies/location db etc provide the routing. Let us consider the case of misrouting. In case of REQUEST misrouting, either other proxies will return "404 Not found" or other error codes. In case of RESPONSE misrouting, REQUESTS will time -out. These excessive errors will alert the IPS/IDS and Administrators can take the corrective actions. This misrouting is happening among the trusted proxies (which may be trusted for other domain) and SIP messages are only accessible to trusted proxies. Here trust breach is happening at the application layer, and attackers cannot get anything if they are tapping on the wires. SIP message details are open to *Administrators* of other proxies. =20 Now consider the case of usage of bad ciphers. If misconfigured/bad/buggy etc proxy uses the less secure (e.g. 40 bit) cipher, then details can be found by the attachers if they are tapping on the wire. If no of less secure hops increases then it gives attackers more choices to access the SIP message contents. If misconfigured proxy at the first hop itself uses the less secure stuff, then attackers have a gold mine as the entire chain becomes less secure, though it was not expected by the UAC. Spammers will get another place to learn the URI's.=20 =20 So we need a separate header. Proxies misconfigured etc with ciphers opens the details on the wire. They should be verified at each hop. Thx Dean for "Trust and Verify" idiom. Adjacent proxy collobaration was mentione in the draft too. =20 2) BTW, Eric was in agreement for extending the via for including the cipher-suite and for the reverse channel. He mentioned that MTA's add this too.=20 =20 3) For the future proofness of Secure Protocols, it will be good to design the SIP with that in mind. Think outside of the current islands deployments. It will be real difficult to find all the proxies updated with the secure protocols etc to be developed in future. There may be some providers, who might be providing the zero hour etc updates and their may be others who might be lacking. Providers may be charging based on the level of security too. It does consitute in their reputation also. So it's better to have it exposed to the users who care about this.=20 4) On one channel there will be one cipher-suite. So no of ciphers will increase the no of TCP connections. Another reason for connect-reuse. Or we keep on renegotiating the ciphers. =20 Pl voice your concerns, if you think above arguments don't suffice the need of ciphers with a separate header.=20 If we are in agreement, then I will go further for more details in the next version. =20 Thx Samir =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C6B77A.4CACEEF9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1) It was mentioned in the last meeting=20 that  Proxies are trusted = for the=20 other tasks.  So they should be trusted for = the=20 cipher-suite = also. And we need more stark requirement to = justify=20 it.  =

 

    Proxies based on the=20 policies/location db etc provide the routing.=20 Let us consider the case of misrouting.=20 In=20 case of REQUEST misrouting, either other proxies will return "404 Not = found" or other error codes. In case of = RESPONSE=20 misrouting, REQUESTS will time –out.=20 These excessive = errors will=20 alert the IPS/IDS and Administrators can take the corrective actions. = This=20 misrouting is happening among the trusted proxies=20 (which may be trusted for other domain) and SIP messages are only = accessible to trusted proxies.  Here trust breach is happening = at the=20 application layer, and attackers cannot get anything if they are = tapping on the wires.  SIP message details are open to *Administrators* of other proxies.

 

    Now consider the case = of usage=20 of bad ciphers.  If misconfigured/bad/buggy etc proxy = uses the=20 less secure (e.g. 40 bit) cipher, then details can be found by = the=20 attachers if they are tapping on the wire. If =  no of less secure = hops=20 increases then it gives = attackers=20 more choices  to = access the SIP=20 message contents.  If = misconfigured proxy at the first hop = itself uses the less=20 secure stuff, then attackers have a gold mine as the entire chain = becomes less secure, = though it was=20 not expected by the UAC. Spammers will get another place to learn the = URI's.=20

 

    So we need a = separate header.=20 Proxies misconfigured = etc with=20 ciphers opens the details on the wire.=20 They should be verified at each hop. Thx Dean for "Trust and Verify"=20 idiom. Adjacent proxy=20 collobaration was mentione in the draft too.

 
2) BTW,  Eric was in agreement for = extending=20 the via for including the cipher-suite and = for the=20 reverse channel. He mentioned that MTA's add this too.=20

 

3) For the future proofness of Secure = Protocols, it=20 will be good to design the SIP with that in mind. Think outside of the = current=20 islands deployments. It will be real difficult to find all the proxies = updated=20 with the secure protocols etc to be developed in future. There may be = some=20 providers, who might be providing the zero hour etc updates and their = may=20 be  others who might be lacking. Providers may be charging based on = the=20 level of security too. It does consitute in their reputation also. So = it's=20 better to have it exposed to the users who care about this.=20


4) On one channel there will be one cipher-suite. So = no of=20 ciphers will increase the no of TCP connections. Another reason for connect-reuse. Or we keep on renegotiating the = ciphers.

 

  Pl voice your concerns, if you = think=20 above arguments don’t = suffice the need of=20 ciphers with a separate header.=20

  If we are in agreement, then I will go = further=20 for more details in the next version.

 

Thx

Samir

 

   =

 

 

 

 

  =20

------_=_NextPart_001_01C6B77A.4CACEEF9-- --===============0050730388== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============0050730388==-- From sip-bounces@ietf.org Fri Aug 04 00:45:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8rX3-0006zu-AL; Fri, 04 Aug 2006 00:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8rX2-0006wR-1Y for sip@ietf.org; Fri, 04 Aug 2006 00:43:32 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8rWz-0000KW-MN for sip@ietf.org; Fri, 04 Aug 2006 00:43:32 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 4AABE1E8C1C; Thu, 3 Aug 2006 21:43:29 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA18D8A@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Thu, 03 Aug 2006 21:43:29 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA18D8A@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Thu, 3 Aug 2006 22:58:51 -0500") Message-ID: <86bqr1dsb2.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > 1. (*) text/plain ( ) text/html > > 1) It was mentioned in the last meeting that Proxies are trusted for > the other tasks. So they should be trusted for the cipher-suite also. > And we need more stark requirement to justify it. > > Proxies based on the policies/location db etc provide the routing. > Let us consider the case of misrouting. In case of REQUEST misrouting, > either other proxies will return "404 Not found" or other error codes. > In case of RESPONSE misrouting, REQUESTS will time -out. These excessive > errors will alert the IPS/IDS and Administrators can take the corrective > actions. This misrouting is happening among the trusted proxies (which > may be trusted for other domain) and SIP messages are only accessible to > trusted proxies. Here trust breach is happening at the application > layer, and attackers cannot get anything if they are tapping on the > wires. SIP message details are open to *Administrators* of other > proxies. > > Now consider the case of usage of bad ciphers. If > misconfigured/bad/buggy etc proxy uses the less secure (e.g. 40 bit) > cipher, then details can be found by the attachers if they are tapping > on the wire. If no of less secure hops increases then it gives > attackers more choices to access the SIP message contents. If > misconfigured proxy at the first hop itself uses the less secure stuff, > then attackers have a gold mine as the entire chain becomes less secure, > though it was not expected by the UAC. Spammers will get another place > to learn the URI's. > > So we need a separate header. Proxies misconfigured etc with ciphers > opens the details on the wire. They should be verified at each hop. Thx > Dean for "Trust and Verify" idiom. Adjacent proxy collobaration was > mentione in the draft too. I'm sorry, I don't understand this argument. What functionality are you arguing for? > 2) BTW, Eric was in agreement for extending the via for including the > cipher-suite and for the reverse channel. He mentioned that MTA's add > this too. For signalling purposes only, not for control purposes. I disagree. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 02:23:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8t3g-000555-Cl; Fri, 04 Aug 2006 02:21:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8t3f-000550-Cb for sip@ietf.org; Fri, 04 Aug 2006 02:21:19 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8t3e-0000s2-1h for sip@ietf.org; Fri, 04 Aug 2006 02:21:19 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k746LFQ05657; Fri, 4 Aug 2006 02:21:15 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 01:21:14 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> In-Reply-To: <86bqr1dsb2.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP thread-index: Aca3gIyzXK5XChdkRaucpE55E6ZfswAChE7Q From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, 1) Let me rephrase the first argument. Misconfigured/buggy proxies for the SIP layer result in misrouting of SIP message which will open the SIP message contents only to the Administrators of the proxies. Attackers cannot peak into what is going on the wire. If a proxy is buggy for cipher-suites, then it opens up the channel for the attackers who are tapping the contents on the wire and they can decode the contents say if it is 40 bits. Here=20 we need to be more careful. =20 =20 UAC may be configured for using any ciphers when they are dialing 911. And when it is talking to bank with a/c no etc in KPML, or in IM session with payload having a/c no, in similar scenarios, it may want to use AES256 only. In AES256 request, a buggy or cheater proxy may provide the service which it should not do. If that proxy doesn't provide the service, then it will loose the revenue. It should be checked just at the next hop. Otherwise this proxy opens up the chain further down the line too for attackers. Without a separate header UAC will come to know about the breach when it gets the response. By this time it is too late. 2) For the second comment, I will leave up to the User Agent clients to decide how they want to interpret. IMHO, Control action is user driven and we don't need to standardize. =20 Thx Samir > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 > Sent: Thursday, August 03, 2006 9:43 PM > To: Srivastava, Samir (SC100:8826) > Cc: sip@ietf.org > Subject: Re: [Sip] Ciphersuites in SIP >=20 > "Samir Srivastava" writes: >=20 > > 1. (*) text/plain ( ) text/html =20 > > > > 1) It was mentioned in the last meeting that Proxies are=20 > trusted for=20 > > the other tasks. So they should be trusted for the=20 > cipher-suite also. > > And we need more stark requirement to justify it. =20 > > =20 > > Proxies based on the policies/location db etc provide=20 > the routing. > > Let us consider the case of misrouting. In case of REQUEST=20 > misrouting,=20 > > either other proxies will return "404 Not found" or other=20 > error codes. > > In case of RESPONSE misrouting, REQUESTS will time -out. These=20 > > excessive errors will alert the IPS/IDS and Administrators can take=20 > > the corrective actions. This misrouting is happening among=20 > the trusted=20 > > proxies (which may be trusted for other domain) and SIP=20 > messages are=20 > > only accessible to trusted proxies. Here trust breach is=20 > happening at=20 > > the application layer, and attackers cannot get anything if=20 > they are=20 > > tapping on the wires. SIP message details are open to=20 > > *Administrators* of other proxies. > > > > Now consider the case of usage of bad ciphers. If=20 > > misconfigured/bad/buggy etc proxy uses the less secure=20 > (e.g. 40 bit)=20 > > cipher, then details can be found by the attachers if they=20 > are tapping=20 > > on the wire. If no of less secure hops increases then it gives=20 > > attackers more choices to access the SIP message contents. If=20 > > misconfigured proxy at the first hop itself uses the less secure=20 > > stuff, then attackers have a gold mine as the entire chain becomes=20 > > less secure, though it was not expected by the UAC.=20 > Spammers will get=20 > > another place to learn the URI's. > > =20 > > So we need a separate header. Proxies misconfigured etc with=20 > > ciphers opens the details on the wire. They should be=20 > verified at each=20 > > hop. Thx Dean for "Trust and Verify" idiom. Adjacent proxy=20 > > collobaration was mentione in the draft too. >=20 > I'm sorry, I don't understand this argument. What=20 > functionality are you arguing for? >=20 >=20 > > 2) BTW, Eric was in agreement for extending the via for=20 > including the=20 > > cipher-suite and for the reverse channel. He mentioned that=20 > MTA's add=20 > > this too. >=20 > For signalling purposes only, not for control purposes. >=20 > I disagree. >=20 > -Ekr >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 04:07:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ugy-0007G6-U4; Fri, 04 Aug 2006 04:06:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ugx-0007Fy-4u for sip@ietf.org; Fri, 04 Aug 2006 04:05:59 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8ugv-0003gq-Kg for sip@ietf.org; Fri, 04 Aug 2006 04:05:59 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Fri, 4 Aug 2006 10:05:54 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Aug 2006 10:05:54 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A6D3@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: sanjsinh@cisco.com, jdrosen@cisco.com, sip@ietf.org Subject: AW: [Sip] updated acr code draft Date: Fri, 4 Aug 2006 10:05:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If you are looking on the Interworking specifications Q.1912.5 = (ISUP-SIP) from ITU-T or also the TISPAN Spec ETSI ES 283 027/3GPP = TS29.163 a IAM with no Calling Party number will be interworked to an = >From header with the content 'unavailable@hostportion'. So the INVITE = is marked not anonymus and the call will be sucessfull in the ACR case. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com]=20 > Gesendet: Donnerstag, 3. August 2006 15:57 > An: Jesske, Roland; Jonathan Rosenberg (jdrosen); sip@ietf.org > Betreff: RE: [Sip] updated acr code draft >=20 >=20 > Scenario is PSTN-SIP interworking. For some cases, display IE=20 > is not available in SETUP because some TCAP query is=20 > required. When the query is complete, switch sends display IE=20 > in a FACILITY message. From header is mandatory in INVITE,=20 > but calling name and number is not. So Invite is sent without=20 > caller-identity which is later updated with an UPDATE/INFO,=20 > when the UA gets FACILITY with display information. >=20 > Thanks > Sanjay.=20 >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > Sent: Thursday, August 03, 2006 1:52 AM > To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen);=20 > sip@ietf.org > Subject: AW: [Sip] updated acr code draft >=20 > The ACR service itself reacts only on identities that are put=20 > anonymus by the user or on behalf on the user. > So if the restriction is based on other reasons ACR will not=20 > terminate the call. >=20 > My question to your scenario is in which case an identity is=20 > not available in an INVITE. The From header is an mandatory=20 > header so the >From Header has have an user identity. Or not? >=20 > The P-Asserted-Identity is set by an trusted network entity=20 > that is aware of the user sending that request. >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > Gesendet: Mittwoch, 2. August 2006 17:32 > > An: Jonathan Rosenberg (jdrosen); IETF SIP List > > Betreff: RE: [Sip] updated acr code draft > >=20 > >=20 > > What about the case in which caller information is not available at = > > the time INVITE is sent to establish a call, but is available later = > > and an UPDATE/INFO is sent by UAC to update the caller-id=20 > information.=20 > > If UAS rejects UPDATE/INFO with 433, what does it mean for=20 > the Invite=20 > > dialog. > > Should that also be terminated as a result of ACR? > >=20 > > Thanks > > Sanjay > >=20 > > -----Original Message----- > > From: Jonathan Rosenberg (jdrosen) > > Sent: Monday, July 31, 2006 4:31 PM > > To: IETF SIP List > > Subject: [Sip] updated acr code draft > >=20 > > I've submitted a minor update to the ACR code draft. Until=20 > it appears,=20 > > you can pick it up at: > >=20 > > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt > >=20 > > the changes are: > >=20 > > * replaced P-Asserted-ID with P-Asserted-Identity > >=20 > > * added to security considerations section, consideration for=20 > > anonymizers in the network. Namely, don't retry request on=20 > receipt of > > 433 unless explicitly configured to do so by user > >=20 > >=20 > > Thanks, > > Jonathan R. > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ=20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) = 952-5050 > > http://www.jdrosen.net PHONE: (973) = 952-5000 > > http://www.cisco.com > >=20 > > _______________________________________________ > > Sip mailing list https://www1.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 > > sipping@ietf.org for new developments on the application of sip > >=20 > > _______________________________________________ > > Sip mailing list https://www1.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 > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 04 04:38:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vAS-0002m9-3y; Fri, 04 Aug 2006 04:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vAQ-0002ll-TZ for sip@ietf.org; Fri, 04 Aug 2006 04:36:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8vAQ-0008Gp-Q7 for sip@ietf.org; Fri, 04 Aug 2006 04:36:26 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8up1-0000vn-9p for sip@ietf.org; Fri, 04 Aug 2006 04:14:21 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Fri, 4 Aug 2006 10:14:09 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Aug 2006 10:14:09 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A6D4@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: maltarai@cisco.com, sanjsinh@cisco.com, jdrosen@cisco.com, sip@ietf.org Subject: AW: [Sip] updated acr code draft Date: Fri, 4 Aug 2006 10:14:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There is a difference between an unavailable identity and a anonymous = identity so that the endpoint can decide. As a wrote before the From header is a mandatory header. So there must = an identity in.=20 In which scenario this early attended transfer could appear is this = also a interworking case or a pure SIP case? What is with the identity I'm registering with? BR Roland > -----Urspr=FCngliche Nachricht----- > Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com]=20 > Gesendet: Donnerstag, 3. August 2006 16:22 > An: Sanjay Sinha (sanjsinh); Jesske, Roland; Jonathan=20 > Rosenberg (jdrosen); sip@ietf.org > Cc: Mohammad Al-Taraireh (maltarai) > Betreff: RE: [Sip] updated acr code draft >=20 >=20 >=20 > Another case is a early attended transfer. For example the=20 > transfer target will get an INVITE without caller id blocking=20 > and then an UPDATE after the xfer with caller id blocking to=20 > change the display. If there is a policy on the endpoint to=20 > reject anonymous calls, what should the=20 > do in this case? which the question below "what does 433 mean=20 > for mid call UPDATE or reINVITE?" >=20 > Thanks, >=20 > Mo=20 >=20 > -----Original Message----- > From: Sanjay Sinha (sanjsinh)=20 > Sent: Thursday, August 03, 2006 9:57 AM > To: Jesske, R; Jonathan Rosenberg (jdrosen); sip@ietf.org > Subject: RE: [Sip] updated acr code draft >=20 > Scenario is PSTN-SIP interworking. For some cases, display IE=20 > is not available in SETUP because some TCAP query is=20 > required. When the query is complete, switch sends display IE=20 > in a FACILITY message. From header is mandatory in INVITE,=20 > but calling name and number is not. So Invite is sent without=20 > caller-identity which is later updated with an UPDATE/INFO,=20 > when the UA gets FACILITY with display information. >=20 > Thanks > Sanjay.=20 >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: Thursday, August 03, 2006 1:52 AM > To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen);=20 > sip@ietf.org > Subject: AW: [Sip] updated acr code draft >=20 > The ACR service itself reacts only on identities that are put=20 > anonymus by the user or on behalf on the user. > So if the restriction is based on other reasons ACR will not=20 > terminate the call. >=20 > My question to your scenario is in which case an identity is=20 > not available in an INVITE. The From header is an mandatory=20 > header so the >From Header has have an user identity. Or not? >=20 > The P-Asserted-Identity is set by an trusted network entity=20 > that is aware of the user sending that request. >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > Gesendet: Mittwoch, 2. August 2006 17:32 > > An: Jonathan Rosenberg (jdrosen); IETF SIP List > > Betreff: RE: [Sip] updated acr code draft > >=20 > >=20 > > What about the case in which caller information is not available at = > > the time INVITE is sent to establish a call, but is available later = > > and an UPDATE/INFO is sent by UAC to update the caller-id=20 > information. > > If UAS rejects UPDATE/INFO with 433, what does it mean for=20 > the Invite=20 > > dialog. > > Should that also be terminated as a result of ACR? > >=20 > > Thanks > > Sanjay > >=20 > > -----Original Message----- > > From: Jonathan Rosenberg (jdrosen) > > Sent: Monday, July 31, 2006 4:31 PM > > To: IETF SIP List > > Subject: [Sip] updated acr code draft > >=20 > > I've submitted a minor update to the ACR code draft. Until=20 > it appears,=20 > > you can pick it up at: > >=20 > > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt > >=20 > > the changes are: > >=20 > > * replaced P-Asserted-ID with P-Asserted-Identity > >=20 > > * added to security considerations section, consideration for > > anonymizers in the network. Namely, don't retry request on=20 > receipt of > > 433 unless explicitly configured to do so by user > >=20 > >=20 > > Thanks, > > Jonathan R. > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ=20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) = 952-5050 > > http://www.jdrosen.net PHONE: (973) = 952-5000 > > http://www.cisco.com > >=20 > > _______________________________________________ > > Sip mailing list https://www1.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://www1.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 > _______________________________________________ > Sip mailing list https://www1.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 > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 04 08:45:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8z1Z-0002P5-Vg; Fri, 04 Aug 2006 08:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8z1Y-0002Oz-8A for sip@ietf.org; Fri, 04 Aug 2006 08:43:32 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8z1W-0000dU-Ow for sip@ietf.org; Fri, 04 Aug 2006 08:43:32 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2006 05:43:30 -0700 X-IronPort-AV: i="4.07,211,1151910000"; d="scan'208"; a="438805127:sNHT27675816" 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.20060308/8.12.11) with ESMTP id k74ChTAY000624; Fri, 4 Aug 2006 05:43:29 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k74ChTUs003272; Fri, 4 Aug 2006 05:43:29 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k74Ca6LK031079; Fri, 4 Aug 2006 05:36:06 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1CCA191B-0B31-4A7C-A7C2-B7C07489A859@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 08:43:24 -0400 To: "Samir Srivastava" X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-2.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=4651; t=1154695409; x=1155559409; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[Sip]=20Ciphersuites=20in=20SIP; X=v=3Dcisco.com=3B=20h=3DjkLDzvvSm+nUMbRaSTab5J0UlXQ=3D; b=2Tq6gTf2C8goDCjSHridUHedUmv8rUMR2/1XStijd0F5KKWKV7EqIVn1UvLsSa/G9TyVE1AC C0Qq3UZZ8cJ7hjP8YJ29/kXyzjSWVj/X3etc0Mea1qIuMf3065DDpGxD; X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 4, 2006, at 2:21 AM, Samir Srivastava wrote: > Hi Eric, > > 1) Let me rephrase the first argument. > > Misconfigured/buggy proxies for the SIP layer result in misrouting of > SIP message which will open the SIP message contents only to the > Administrators of the proxies. Attackers cannot peak into what is > going > on the wire. > > If a proxy is buggy for cipher-suites, then it opens up the channel > for > the attackers who are tapping the contents on the wire and they can > decode the contents say if it is 40 bits. Here > we need to be more careful. > You mean we forgot these in the requirements document: Req 1A: Proxies MUST NOT have any bugs. Req 1B: Proxies MUST NOT be misconfigured by administrators Ah, that makes me feel better. Dave. > UAC may be configured for using any ciphers when they are dialing 911. > And when it is talking to bank with a/c no etc in KPML, or in IM > session > with payload having a/c no, in similar scenarios, it may want to use > AES256 only. In AES256 request, a buggy or cheater proxy may > provide the > service which it should not do. If that proxy doesn't provide the > service, then it will loose the revenue. It should be checked just at > the next hop. Otherwise this proxy opens up the chain further down the > line too for attackers. Without a separate header UAC will come to > know > about the breach when it gets the response. By this time it is too > late. > > 2) For the second comment, I will leave up to the User Agent > clients to > decide how they want to interpret. IMHO, Control action is user driven > and we don't need to standardize. > > Thx > Samir > >> -----Original Message----- >> From: Eric Rescorla [mailto:ekr@networkresonance.com] >> Sent: Thursday, August 03, 2006 9:43 PM >> To: Srivastava, Samir (SC100:8826) >> Cc: sip@ietf.org >> Subject: Re: [Sip] Ciphersuites in SIP >> >> "Samir Srivastava" writes: >> >>> 1. (*) text/plain ( ) text/html >>> >>> 1) It was mentioned in the last meeting that Proxies are >> trusted for >>> the other tasks. So they should be trusted for the >> cipher-suite also. >>> And we need more stark requirement to justify it. >>> >>> Proxies based on the policies/location db etc provide >> the routing. >>> Let us consider the case of misrouting. In case of REQUEST >> misrouting, >>> either other proxies will return "404 Not found" or other >> error codes. >>> In case of RESPONSE misrouting, REQUESTS will time -out. These >>> excessive errors will alert the IPS/IDS and Administrators can take >>> the corrective actions. This misrouting is happening among >> the trusted >>> proxies (which may be trusted for other domain) and SIP >> messages are >>> only accessible to trusted proxies. Here trust breach is >> happening at >>> the application layer, and attackers cannot get anything if >> they are >>> tapping on the wires. SIP message details are open to >>> *Administrators* of other proxies. >>> >>> Now consider the case of usage of bad ciphers. If >>> misconfigured/bad/buggy etc proxy uses the less secure >> (e.g. 40 bit) >>> cipher, then details can be found by the attachers if they >> are tapping >>> on the wire. If no of less secure hops increases then it gives >>> attackers more choices to access the SIP message contents. If >>> misconfigured proxy at the first hop itself uses the less secure >>> stuff, then attackers have a gold mine as the entire chain becomes >>> less secure, though it was not expected by the UAC. >> Spammers will get >>> another place to learn the URI's. >>> >>> So we need a separate header. Proxies misconfigured etc with >>> ciphers opens the details on the wire. They should be >> verified at each >>> hop. Thx Dean for "Trust and Verify" idiom. Adjacent proxy >>> collobaration was mentione in the draft too. >> >> I'm sorry, I don't understand this argument. What >> functionality are you arguing for? >> >> >>> 2) BTW, Eric was in agreement for extending the via for >> including the >>> cipher-suite and for the reverse channel. He mentioned that >> MTA's add >>> this too. >> >> For signalling purposes only, not for control purposes. >> >> I disagree. >> >> -Ekr >> > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 04 09:24:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8zdR-000553-OE; Fri, 04 Aug 2006 09:22:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8zdQ-00054y-HO for sip@ietf.org; Fri, 04 Aug 2006 09:22:40 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8zdO-0007Jj-93 for sip@ietf.org; Fri, 04 Aug 2006 09:22:40 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc13) with ESMTP id <20060804132237b1300ht32ee>; Fri, 4 Aug 2006 13:22:37 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k74DMbZW009476 for ; Fri, 4 Aug 2006 09:22:37 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k74DMaA5009472; Fri, 4 Aug 2006 09:22:36 -0400 Date: Fri, 4 Aug 2006 09:22:36 -0400 Message-Id: <200608041322.k74DMaA5009472@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Sip] draft-ietf-sip-gruu-10.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I read section 8 of the -10 draft to see if certain passages I'd been having trouble understanding had been resolved, and I ran into the following difficulties: In 8.2.2, I see "The rules in Section 8.1.1 ensure that at least one proxy in the same domain of the home proxy will be visited." In the context, it appears that this is stating that 8.1.1 ensures that a UA in a domain that issues GRUUs will always have its UAs use an outbound proxy. And yet I can't see how 8.1.1 forces that, especially in light of the statement "Note that this specification does not require the use of an outbound proxy". And some wording issues: When using a service route, this requirement (that the GRUU be obtained from a domain that will be visited by the request) it is sufficient to use the GRUU learned in the same registration that delivered the service route. This doesn't parse. Possibly it should read "... to satisfy this requirement (...), it is sufficient ...". Note that this specification does not require the use of an outbound proxy; it merely introduces the previous requirements in cases where one is used. I think that "previous" won't be read as intended, as I interpreted it to mean "backward in time (to RFC 3261)", not "the previous paragraph in this document". How about "...; but in cases where one is used, it adds the above requirements."? The rules in Section 8.1.1 ensure that at least one proxy in the same domain of the home proxy will be visited. "the same domain of" s.b. "the domain of". Also, this entire paragraph is written in reverse logical sequence. IMHO, it's better to give causes before effects, even if that delays stating the requirement itself: Firstly: The rules in Section 8.1.1 ensure that at least one proxy in the same domain of the home proxy will be visited. A home proxy can use mechanisms such as Service-Route [27] or UA configuration to ensure that it, or a proxy in the same domain, is on the outgoing request path. If such a proxy receives a dialog forming request from a UA in its own domain (an originating request) whose Contact header field contains a GRUU (indicated by the presence of the "gruu" URI parameter) that is also in that domain, the proxy MUST generate a record-route which will route to the home proxy. Of course, this is dependent on resolving the content issue above. Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 10:16:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90RR-00051W-Vg; Fri, 04 Aug 2006 10:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90RQ-00051Q-EA for sip@ietf.org; Fri, 04 Aug 2006 10:14:20 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G90RP-0007BK-0O for sip@ietf.org; Fri, 04 Aug 2006 10:14:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Aug 2006 07:13:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,211,1151910000"; d="scan'208"; a="34589895:sNHT42281012" 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.20060308/8.12.11) with ESMTP id k74EDNlt004353; Fri, 4 Aug 2006 10:13:23 -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.12.10/8.12.6) with ESMTP id k74EDMe4001137; Fri, 4 Aug 2006 10:13:23 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 10:13:22 -0400 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 Subject: RE: [Sip] updated acr code draft Date: Fri, 4 Aug 2006 10:13:21 -0400 Message-ID: <47F3B0799A62BB48B096A4DC5BB3B11D01C708FB@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] updated acr code draft Thread-Index: Aca3nfrjRRDttdPjR9GfdXSEJXKo9gAMbg1A From: "Mohammad Al-Taraireh \(maltarai\)" To: "Jesske, R" , "Sanjay Sinha \(sanjsinh\)" , "Jonathan Rosenberg \(jdrosen\)" , X-OriginalArrivalTime: 04 Aug 2006 14:13:22.0962 (UTC) FILETIME=[25117720:01C6B7D0] DKIM-Signature: a=rsa-sha1; q=dns; l=6419; t=1154700803; x=1155564803; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=maltarai@cisco.com; z=From:=22Mohammad=20Al-Taraireh=20\(maltarai\)=22=20 |Subject:RE=3A=20[Sip]=20updated=20acr=20code=20draft |To:=22Jesske, =20R=22=20, =0A=20=20=20=20=20=20=20=20=22S anjay=20Sinha=20\(sanjsinh\)=22=20, =0A=20=20=20=20=20=2 0=20=20=22Jonathan=20Rosenberg=20\(jdrosen\)=22=20, =20; X=v=3Dcisco.com=3B=20h=3D7AnlpAKvVe8FqShot/tfaxrRQpU=3D; b=Cm/0+OrtjC/p9yPz6O+xPiSG/K7MBEGm2pGEGpUHJB7TRXI/kKIviH9jyo0Kqt4tUMsoOad/ H6ygf8k0H4nXNjenKlJ6zn1We36ipz82xZKh/VdZZtQz8arrTdi/znSp; Authentication-Results: rtp-dkim-1.cisco.com; header.From=maltarai@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The identity in the From header in not the correct party after the xfer = is complete! I still don't see an answer to what should the UAC do when it gets the 433 response, or what the UAS should do after it = send the 433, basically how does that response impact the INVITE dialog. Thanks, Mo=20 -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: Friday, August 04, 2006 4:14 AM To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh); Jonathan = Rosenberg (jdrosen); sip@ietf.org Subject: AW: [Sip] updated acr code draft There is a difference between an unavailable identity and a anonymous = identity so that the endpoint can decide. As a wrote before the From header is a mandatory header. So there must = an identity in.=20 In which scenario this early attended transfer could appear is this also = a interworking case or a pure SIP case? What is with the identity I'm registering with? BR Roland > -----Urspr=FCngliche Nachricht----- > Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] > Gesendet: Donnerstag, 3. August 2006 16:22 > An: Sanjay Sinha (sanjsinh); Jesske, Roland; Jonathan Rosenberg=20 > (jdrosen); sip@ietf.org > Cc: Mohammad Al-Taraireh (maltarai) > Betreff: RE: [Sip] updated acr code draft >=20 >=20 >=20 > Another case is a early attended transfer. For example the transfer=20 > target will get an INVITE without caller id blocking and then an=20 > UPDATE after the xfer with caller id blocking to change the display.=20 > If there is a policy on the endpoint to reject anonymous calls, what=20 > should the do in this case? which the question below "what does 433=20 > mean for mid call UPDATE or reINVITE?" >=20 > Thanks, >=20 > Mo >=20 > -----Original Message----- > From: Sanjay Sinha (sanjsinh) > Sent: Thursday, August 03, 2006 9:57 AM > To: Jesske, R; Jonathan Rosenberg (jdrosen); sip@ietf.org > Subject: RE: [Sip] updated acr code draft >=20 > Scenario is PSTN-SIP interworking. For some cases, display IE is not=20 > available in SETUP because some TCAP query is required. When the query = > is complete, switch sends display IE in a FACILITY message. From=20 > header is mandatory in INVITE, but calling name and number is not. So=20 > Invite is sent without caller-identity which is later updated with an=20 > UPDATE/INFO, when the UA gets FACILITY with display information. >=20 > Thanks > Sanjay.=20 >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: Thursday, August 03, 2006 1:52 AM > To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen);=20 > sip@ietf.org > Subject: AW: [Sip] updated acr code draft >=20 > The ACR service itself reacts only on identities that are put anonymus = > by the user or on behalf on the user. > So if the restriction is based on other reasons ACR will not terminate = > the call. >=20 > My question to your scenario is in which case an identity is not=20 > available in an INVITE. The From header is an mandatory header so the=20 > >From Header has have an user identity. Or not? >=20 > The P-Asserted-Identity is set by an trusted network entity that is=20 > aware of the user sending that request. >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > Gesendet: Mittwoch, 2. August 2006 17:32 > > An: Jonathan Rosenberg (jdrosen); IETF SIP List > > Betreff: RE: [Sip] updated acr code draft > >=20 > >=20 > > What about the case in which caller information is not available at=20 > > the time INVITE is sent to establish a call, but is available later=20 > > and an UPDATE/INFO is sent by UAC to update the caller-id > information. > > If UAS rejects UPDATE/INFO with 433, what does it mean for > the Invite > > dialog. > > Should that also be terminated as a result of ACR? > >=20 > > Thanks > > Sanjay > >=20 > > -----Original Message----- > > From: Jonathan Rosenberg (jdrosen) > > Sent: Monday, July 31, 2006 4:31 PM > > To: IETF SIP List > > Subject: [Sip] updated acr code draft > >=20 > > I've submitted a minor update to the ACR code draft. Until > it appears, > > you can pick it up at: > >=20 > > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt > >=20 > > the changes are: > >=20 > > * replaced P-Asserted-ID with P-Asserted-Identity > >=20 > > * added to security considerations section, consideration for=20 > > anonymizers in the network. Namely, don't retry request on > receipt of > > 433 unless explicitly configured to do so by user > >=20 > >=20 > > Thanks, > > Jonathan R. > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ=20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > >=20 > > _______________________________________________ > > Sip mailing list https://www1.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://www1.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 > _______________________________________________ > Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 04 12:11:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92Er-0006oB-O7; Fri, 04 Aug 2006 12:09:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92Eq-0006o1-0d for sip@ietf.org; Fri, 04 Aug 2006 12:09:28 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G92Eo-0008MU-MO for sip@ietf.org; Fri, 04 Aug 2006 12:09:27 -0400 Received: from [192.168.2.104] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k74GBXva012219 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Aug 2006 11:11:34 -0500 In-Reply-To: <1CCA191B-0B31-4A7C-A7C2-B7C07489A859@cisco.com> References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <1CCA191B-0B31-4A7C-A7C2-B7C07489A859@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <62B8B1BC-6264-4818-A170-A5B273B1EE6C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 11:09:24 -0500 To: David R Oran X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 4, 2006, at 7:43 AM, David R Oran wrote: >> > You mean we forgot these in the requirements document: > > Req 1A: Proxies MUST NOT have any bugs. > Req 1B: Proxies MUST NOT be misconfigured by administrators > > Ah, that makes me feel better. There's the germ of an idea here that may make you feel better. If we assume that we typically have a proxy chain -- that is, a sequence of multiple proxies, the likeliest failure mode is that not ALL of those proxies are misconfigured or buggy in exactly the same way. So if each proxy knows what sort of behavior is expected, perhaps it can "rat out" a neighbor that isn't behaving correctly. This will at least give us a couple of places to look for bugs or misconfigurations -- either the complaining proxy is wrong. or the proxy it is complaining about is wrong. So the "germ" here is that we might be able to inform the proxies about the cryptographic expectations such that when a peer deviates from those expectations the proxy knows to take action. Sure, this won't catch some "evil" proxies that alter the expectations -- just stupid ones -- but that's arguably better than nothing. -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 12:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92VU-00052X-Dc; Fri, 04 Aug 2006 12:26:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92VS-00051f-OI for sip@ietf.org; Fri, 04 Aug 2006 12:26:38 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G92VE-0001XV-AW for sip@ietf.org; Fri, 04 Aug 2006 12:26:26 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id D67751E8C1C; Fri, 4 Aug 2006 09:26:23 -0700 (PDT) To: Dean Willis Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <1CCA191B-0B31-4A7C-A7C2-B7C07489A859@cisco.com> <62B8B1BC-6264-4818-A170-A5B273B1EE6C@softarmor.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 09:26:23 -0700 In-Reply-To: <62B8B1BC-6264-4818-A170-A5B273B1EE6C@softarmor.com> (Dean Willis's message of "Fri, 4 Aug 2006 11:09:24 -0500") Message-ID: <86zmekbh74.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org, David R Oran X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > On Aug 4, 2006, at 7:43 AM, David R Oran wrote: > >>> >> You mean we forgot these in the requirements document: >> >> Req 1A: Proxies MUST NOT have any bugs. >> Req 1B: Proxies MUST NOT be misconfigured by administrators >> >> Ah, that makes me feel better. > > There's the germ of an idea here that may make you feel better. > > If we assume that we typically have a proxy chain -- that is, a > sequence of multiple proxies, the likeliest failure mode is that not > ALL of those proxies are misconfigured or buggy in exactly the same > way. > > So if each proxy knows what sort of behavior is expected, perhaps it > can "rat out" a neighbor that isn't behaving correctly. This will at > least give us a couple of places to look for bugs or > misconfigurations -- either the complaining proxy is wrong. or the > proxy it is complaining about is wrong. > > So the "germ" here is that we might be able to inform the proxies > about the cryptographic expectations such that when a peer deviates > from those expectations the proxy knows to take action. Sure, this > won't catch some "evil" proxies that alter the expectations -- just > stupid ones -- but that's arguably better than nothing. No, I don't think it is better than nothing. It's primarily added complexity to compensate for a case which we have no particular reason to believe will occur. I agree it's useful for a message recipient to know what processing was applied to the messages, but I don't think that automatic defection detection is particularly useful. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 12:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92VW-000553-Jp; Fri, 04 Aug 2006 12:26:42 -0400 Received: from [10.91.34From sip-bounces@ietf.org Fri Aug 04 12:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92VU-00052X-Dc; Fri, 04 Aug 2006 12:26:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92VS-00051f-OI for sip@ietf.org; Fri, 04 Aug 2006 12:26:38 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G92VE-0001XV-AW for sip@ietf.org; Fri, 04 Aug 2006 12:26:26 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id D67751E8C1C; Fri, 4 Aug 2006 09:26:23 -0700 (PDT) To: Dean Willis Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <1CCA191B-0B31-4A7C-A7C2-B7C07489A859@cisco.com> <62B8B1BC-6264-4818-A170-A5B273B1EE6C@softarmor.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 09:26:23 -0700 In-Reply-To: <62B8B1BC-6264-4818-A170-A5B273B1EE6C@softarmor.com> (Dean Willis's message of "Fri, 4 Aug 2006 11:09:24 -0500") Message-ID: <86zmekbh74.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org, David R Oran X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > On Aug 4, 2006, at 7:43 AM, David R Oran wrote: > >>> >> You mean we forgot these in the requirements document: >> >> Req 1A: Proxies MUST NOT have any bugs. >> Req 1B: Proxies MUST NOT be misconfigured by administrators >> >> Ah, that makes me feel better. > > There's the germ of an idea here that may make you feel better. > > If we assume that we typically have a proxy chain -- that is, a > sequence of multiple proxies, the likeliest failure mode is that not > ALL of those proxies are misconfigured or buggy in exactly the same > way. > > So if each proxy knows what sort of behavior is expected, perhaps it > can "rat out" a neighbor that isn't behaving correctly. This will at > least give us a couple of places to look for bugs or > misconfigurations -- either the complaining proxy is wrong. or the > proxy it is complaining about is wrong. > > So the "germ" here is that we might be able to inform the proxies > about the cryptographic expectations such that when a peer deviates > from those expectations the proxy knows to take action. Sure, this > won't catch some "evil" proxies that alter the expectations -- just > stupid ones -- but that's arguably better than nothing. No, I don't think it is better than nothing. It's primarily added complexity to compensate for a case which we have no particular reason to believe will occur. I agree it's useful for a message recipient to know what processing was applied to the messages, but I don't think that automatic defection detection is particularly useful. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 12:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92VW-000553-Jp; Fri, 04 Aug 2006 12:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92VT-000528-W4 for sip@ietf.org; Fri, 04 Aug 2006 12:26:39 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G92TZ-0001Uh-9z for sip@ietf.org; Fri, 04 Aug 2006 12:24:42 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 61FEA1E8C1C; Fri, 4 Aug 2006 09:24:40 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 09:24:40 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Fri, 4 Aug 2006 01:21:14 -0500") Message-ID: <86ac6kcvuf.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > Hi Eric, > > 1) Let me rephrase the first argument. > > Misconfigured/buggy proxies for the SIP layer result in misrouting of > SIP message which will open the SIP message contents only to the > Administrators of the proxies. Attackers cannot peak into what is going > on the wire. That's *one* way for a proxy to be buggy. Another way is to send the message in the clear to some random location. > If a proxy is buggy for cipher-suites, then it opens up the channel for > the attackers who are tapping the contents on the wire and they can > decode the contents say if it is 40 bits. Here > we need to be more careful. I'm sorry, but it's silly to focus on this class of bugs. There are a number of far more obvious SSL-type bugs that compromise security in a far more serious way: bad random number generation being the most obvious one. > UAC may be configured for using any ciphers when they are dialing 911. You do realize that TLS implementations generally automatically negotiate strong algorithms when they're available, right? So in order to get a weak set of ciphers in cases where there's a fairly obvious ranking (as with 40-bit algorithms) you would need to configure your proxy to ONLY do the weak algorithms. That's not a sane configuration. > And when it is talking to bank with a/c no etc in KPML, or in IM session > with payload having a/c no, in similar scenarios, it may want to use > AES256 only. In AES256 request, a buggy or cheater proxy may provide the > service which it should not do. If that proxy doesn't provide the > service, then it will loose the revenue. It should be checked just at > the next hop. Otherwise this proxy opens up the chain further down the > line too for attackers. Without a separate header UAC will come to know > about the breach when it gets the response. By this time it is too late. Well, I don't see any reason to believe this particular class of bugs is particularly likely, so we're back to the case of a malicious proxy. Since such a proxy can trivially modify any signal of what security is expected, there's no reasonable way to prevent this. -Ekr _______________________________________________ Sip mailing list https://www1.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 .44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92VT-000528-W4 for sip@ietf.org; Fri, 04 Aug 2006 12:26:39 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G92TZ-0001Uh-9z for sip@ietf.org; Fri, 04 Aug 2006 12:24:42 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 61FEA1E8C1C; Fri, 4 Aug 2006 09:24:40 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 09:24:40 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Fri, 4 Aug 2006 01:21:14 -0500") Message-ID: <86ac6kcvuf.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > Hi Eric, > > 1) Let me rephrase the first argument. > > Misconfigured/buggy proxies for the SIP layer result in misrouting of > SIP message which will open the SIP message contents only to the > Administrators of the proxies. Attackers cannot peak into what is going > on the wire. That's *one* way for a proxy to be buggy. Another way is to send the message in the clear to some random location. > If a proxy is buggy for cipher-suites, then it opens up the channel for > the attackers who are tapping the contents on the wire and they can > decode the contents say if it is 40 bits. Here > we need to be more careful. I'm sorry, but it's silly to focus on this class of bugs. There are a number of far more obvious SSL-type bugs that compromise security in a far more serious way: bad random number generation being the most obvious one. > UAC may be configured for using any ciphers when they are dialing 911. You do realize that TLS implementations generally automatically negotiate strong algorithms when they're available, right? So in order to get a weak set of ciphers in cases where there's a fairly obvious ranking (as with 40-bit algorithms) you would need to configure your proxy to ONLY do the weak algorithms. That's not a sane configuration. > And when it is talking to bank with a/c no etc in KPML, or in IM session > with payload having a/c no, in similar scenarios, it may want to use > AES256 only. In AES256 request, a buggy or cheater proxy may provide the > service which it should not do. If that proxy doesn't provide the > service, then it will loose the revenue. It should be checked just at > the next hop. Otherwise this proxy opens up the chain further down the > line too for attackers. Without a separate header UAC will come to know > about the breach when it gets the response. By this time it is too late. Well, I don't see any reason to believe this particular class of bugs is particularly likely, so we're back to the case of a malicious proxy. Since such a proxy can trivially modify any signal of what security is expected, there's no reasonable way to prevent this. -Ekr _______________________________________________ Sip mailing list https://www1.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 From sip-bounces@ietf.org Fri Aug 04 12:51:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92ri-00057l-6P; Fri, 04 Aug 2006 12:49:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92rg-00056E-SB for sip@ietf.org; Fri, 04 Aug 2006 12:49:36 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G92io-0002eC-6y for sip@ietf.org; Fri, 04 Aug 2006 12:40:27 -0400 Received: from s73602 (futurewei.com?[65.104.224.98]) by comcast.net (rwcrmhc11) with SMTP id <20060804164024m1100kft4he>; Fri, 4 Aug 2006 16:40:25 +0000 Message-ID: <047d01c6b7e4$8154c280$0600a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <86ac6kcvuf.fsf@raman.networkresonance.com> Subject: Re: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 11:38:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> UAC may be configured for using any ciphers when they are dialing 911. > > You do realize that TLS implementations generally automatically > negotiate strong algorithms when they're available, right? So > in order to get a weak set of ciphers in cases where there's a > fairly obvious ranking (as with 40-bit algorithms) you would > need to configure your proxy to ONLY do the weak algorithms. > That's not a sane configuration. ... and, speaking of sane ... I wouldn't dare characterize the current thinking in ECRIT, the working group that is supposed to be worrying about emergency calling, but a fair amount of discussion there has bounced off the point that getting "I'm sorry, your 911 call isn't secure enough/at all, please hang up and try again while your house is burning down/you're dodging gunfire" isn't sane, either ... so 911 may not be quite the right example here, since it may not be encrypted at all. Hint - cell phone providers are supposed to complete 911 calls even if the cell phone isn't currently subscribed for any other service. Hannes and Marc can talk about all this in more detail, of course. Thanks, Spencer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 12:57:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92xk-0001P0-2A; Fri, 04 Aug 2006 12:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92xj-0001Ov-79 for sip@ietf.org; Fri, 04 Aug 2006 12:55:51 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G92xh-0003rO-TH for sip@ietf.org; Fri, 04 Aug 2006 12:55:51 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 5C8D61E8C1C; Fri, 4 Aug 2006 09:55:49 -0700 (PDT) To: "Spencer Dawkins" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <86ac6kcvuf.fsf@raman.networkresonance.com> <047d01c6b7e4$8154c280$0600a8c0@china.huawei.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 09:55:49 -0700 In-Reply-To: <047d01c6b7e4$8154c280$0600a8c0@china.huawei.com> (Spencer Dawkins's message of "Fri, 4 Aug 2006 11:38:58 -0500") Message-ID: <86psfgbfu2.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Spencer Dawkins" writes: >>> UAC may be configured for using any ciphers when they are dialing 911. >> >> You do realize that TLS implementations generally automatically >> negotiate strong algorithms when they're available, right? So >> in order to get a weak set of ciphers in cases where there's a >> fairly obvious ranking (as with 40-bit algorithms) you would >> need to configure your proxy to ONLY do the weak algorithms. >> That's not a sane configuration. > > ... and, speaking of sane ... > > I wouldn't dare characterize the current thinking in ECRIT, the > working group that is supposed to be worrying about emergency calling, > but a fair amount of discussion there has bounced off the point that > getting "I'm sorry, your 911 call isn't secure enough/at all, please > hang up and try again while your house is burning down/you're dodging > gunfire" isn't sane, either ... so 911 may not be quite the right > example here, since it may not be encrypted at all. Well, as usual there are a number of relevant security services here. In particular, TLS provides a separate: (1) Endpoint authentication and message integrity (2) Confidentiality Provided you want (1), if you configure your phone correctly TLS will securely negotiate (2) or not.... Of course, if you're willing to have your 911 call end up talking to the wrong person, then TLS can't help you, but that has its own threats.... -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 15:10:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G951r-00051j-Go; Fri, 04 Aug 2006 15:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G951p-0004zS-SK for sip@ietf.org; Fri, 04 Aug 2006 15:08:13 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G951o-0004PW-Hz for sip@ietf.org; Fri, 04 Aug 2006 15:08:13 -0400 Received: from [64.101.149.124] (mikwils2-w2k.cisco.com [64.101.149.124]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k74JAJgT012909 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Aug 2006 14:10:20 -0500 In-Reply-To: <86ac6kcvuf.fsf@raman.networkresonance.com> References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <86ac6kcvuf.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DDD6590-6E4C-4E09-9BDD-C46A356B5751@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 14:08:08 -0500 To: EKR X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 4, 2006, at 11:24 AM, Eric Rescorla wrote: > > You do realize that TLS implementations generally automatically > negotiate strong algorithms when they're available, right? So > in order to get a weak set of ciphers in cases where there's a > fairly obvious ranking (as with 40-bit algorithms) you would > need to configure your proxy to ONLY do the weak algorithms. > That's not a sane configuration. > Operators and IT departments often do "insane configurations" for reasons they think are good. Sometimes, one ends up next to a node with an insane configuration. How should one decide whether or not a neighbor is insane and should be treated "carefully"? We deal with humans on this level by having standards and by comparing public behavior against these standards. You can be as crazy as you want in the confines of your own mind as long as nobody notices . . . What we have here is a way of communicating a "standard of behavior" that's established by the end-user -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 15:23:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G95Ea-0008RS-HV; Fri, 04 Aug 2006 15:21:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G95EY-0008F0-CK for sip@ietf.org; Fri, 04 Aug 2006 15:21:22 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G95EX-0006Qr-26 for sip@ietf.org; Fri, 04 Aug 2006 15:21:22 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 663961E8C1C; Fri, 4 Aug 2006 12:21:19 -0700 (PDT) To: Dean Willis Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <86ac6kcvuf.fsf@raman.networkresonance.com> <8DDD6590-6E4C-4E09-9BDD-C46A356B5751@softarmor.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 12:21:19 -0700 In-Reply-To: <8DDD6590-6E4C-4E09-9BDD-C46A356B5751@softarmor.com> (Dean Willis's message of "Fri, 4 Aug 2006 14:08:08 -0500") Message-ID: <86zmek9uj4.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > On Aug 4, 2006, at 11:24 AM, Eric Rescorla wrote: > >> >> You do realize that TLS implementations generally automatically >> negotiate strong algorithms when they're available, right? So >> in order to get a weak set of ciphers in cases where there's a >> fairly obvious ranking (as with 40-bit algorithms) you would >> need to configure your proxy to ONLY do the weak algorithms. >> That's not a sane configuration. >> > > Operators and IT departments often do "insane configurations" for > reasons they think are good. > > Sometimes, one ends up next to a node with an insane configuration. > > How should one decide whether or not a neighbor is insane and should > be treated "carefully"? > > We deal with humans on this level by having standards and by > comparing public behavior against these standards. You can be as > crazy as you want in the confines of your own mind as long as nobody > notices . . . > > What we have here is a way of communicating a "standard of behavior" > that's established by the end-user Again, do you have any evidence this is a problem in real life? There are lots of insane and dangerous things an operator can do. Why should we have protocol support for just this one? -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 15:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G95JT-0006vb-UT; Fri, 04 Aug 2006 15:26:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G95JS-0006vR-RW for sip@ietf.org; Fri, 04 Aug 2006 15:26:27 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G95JR-0007Hp-HM for sip@ietf.org; Fri, 04 Aug 2006 15:26:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G95JJ-0003Lb-3P; Fri, 04 Aug 2006 14:26:17 -0500 From: "Brian Rosen" To: "'Spencer Dawkins'" , Subject: RE: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 15:26:21 -0400 Message-ID: <033a01c6b7fb$dfbc9430$9de6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca35jcDMYalQ3nMTLyaolrSHEANrQAFDrvQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <047d01c6b7e4$8154c280$0600a8c0@china.huawei.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think that there are a bunch of people who will read the specs with selective filtering enabled. You are supposed to first try it with full TLS security, and if it fails, try it again without. You aren't supposed to just start with dropping all the security mechanisms. Specifically, I think a carrier should have persistant TLS connections up to its most commonly used emergency proxies (ESRPs). It may be that in unusual circumstances it cannot rapidly establish a connection, in which case it must try again without TLS. Oh, and BTW, in the U.S., the ciphersuite will be RSA-1024, SHA-1 or 2, and AES. Brian > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Friday, August 04, 2006 12:39 PM > To: sip@ietf.org > Subject: Re: [Sip] Ciphersuites in SIP > > >> UAC may be configured for using any ciphers when they are dialing 911. > > > > You do realize that TLS implementations generally automatically > > negotiate strong algorithms when they're available, right? So > > in order to get a weak set of ciphers in cases where there's a > > fairly obvious ranking (as with 40-bit algorithms) you would > > need to configure your proxy to ONLY do the weak algorithms. > > That's not a sane configuration. > > ... and, speaking of sane ... > > I wouldn't dare characterize the current thinking in ECRIT, the working > group that is supposed to be worrying about emergency calling, but a fair > amount of discussion there has bounced off the point that getting "I'm > sorry, your 911 call isn't secure enough/at all, please hang up and try > again while your house is burning down/you're dodging gunfire" isn't sane, > either ... so 911 may not be quite the right example here, since it may > not > be encrypted at all. > > Hint - cell phone providers are supposed to complete 911 calls even if the > cell phone isn't currently subscribed for any other service. > > Hannes and Marc can talk about all this in more detail, of course. > > Thanks, > > Spencer > > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 04 16:17:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G965B-0006MT-Jy; Fri, 04 Aug 2006 16:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G965A-0006FR-1W for sip@ietf.org; Fri, 04 Aug 2006 16:15:44 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9656-0007XL-IC for sip@ietf.org; Fri, 04 Aug 2006 16:15:44 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k74KFd0q030857 for ; Fri, 4 Aug 2006 22:15:39 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k74KFdJZ010855 for ; Fri, 4 Aug 2006 22:15:39 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 22:15:39 +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: Fri, 4 Aug 2006 22:15:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SDO Emergency Services Coordination Workshop Thread-Index: Aca3F2RxZcMmNsxUTFWlduVgbRSdiwAsgFGQAA3+upA= From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 04 Aug 2006 20:15:39.0388 (UTC) FILETIME=[C0FCDBC0:01C6B802] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] SDO Emergency Services Coordination Workshop X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all,=20 we have organized an SDO Emergency Services Coordination Workshop early October 2006 hosted by Henning Schulzrinne at Columbia University, New York. Detailed information can be found at:=20 http://www.ietf-ecrit.org/EmergencyWorkshop2006/ This event might be interesting for SIP working group members with respect to the SIP emergency call related components. Best regards, Hannes Tschofenig (IETF ECRIT) Marc Linsner (IETF ECRIT) Hannu Hietalahti (3GPP TSG CT chairman) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 16:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G96Sa-0004ud-68; Fri, 04 Aug 2006 16:39:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G96SQ-0004hk-3N for sip@ietf.org; Fri, 04 Aug 2006 16:39:46 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G96SN-0001HK-R4 for sip@ietf.org; Fri, 04 Aug 2006 16:39:46 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k74KdeQ17951; Fri, 4 Aug 2006 16:39:40 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 15:39:24 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DA915F8@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP thread-index: Aca3+y/o/i2+PtpGRlq1HJ01l8d+3AACeKygAAA6vAA= From: "Samir Srivastava" To: "Samir Srivastava" , "EKR" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I am busy with other stuff.=20 Having bugs at other places, doesn't give us excuse to not to fix it. Later write in details. It does expose the Calling numbers etc to the spammers. E164 no are much more densly packed as compared to email addresses. Do we want to design another numbering plan. See how we ran out of IP addresses in V4 etc.... Thx Samir =20 >Again, do you have any evidence this is a problem in real life? >There are lots of insane and dangerous things an operator can >do. Why should we have protocol support for just this one? _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 16:53:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G96dc-0008H9-IO; Fri, 04 Aug 2006 16:51:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G96da-0008H4-Us for sip@ietf.org; Fri, 04 Aug 2006 16:51:18 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G96dZ-0002Ym-KH for sip@ietf.org; Fri, 04 Aug 2006 16:51:18 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k74KpDk14501; Fri, 4 Aug 2006 16:51:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 15:51:08 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DA91621@zrc2hxm2.corp.nortel.com> In-Reply-To: <1CCA191B-0B31-4A7C-A7C2-B7C07489A859@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP thread-index: Aca3w6paFiBNcwdwTbie28NA1gamRgAQstOA From: "Samir Srivastava" To: "David R Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dave, I respectfully disagree here with you.=20 In the real life scenarios, even the mission critical stuff have hit the bugs, where lot of redundancy is employed. We designed the alternate routes, form of proxy servers etc for this... The problem here is misconfigured/cheater proxy is making the system totally unsecure. Consider the following case for the cheater proxy UAC ----> P1 ------> P2 -------> P3 ..... Proxy P1 services to the UAC with the all known latest ciphersuites say AES256 for the current state. But provider of Proxy P2 charges differently to P1 for AES256. And As AES128 current mandatory cipher-suite, it will say let us downgrade it to complete the request. Some old may downgrade it to 3DES. If we don't have a cipher-suites exposed to SIP, users cannot know what is done by the providers... Thx Samir >You mean we forgot these in the requirements document: >Req 1A: Proxies MUST NOT have any bugs. >Req 1B: Proxies MUST NOT be misconfigured by administrators >Ah, that makes me feel better. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 17:23:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G976b-0006H2-6B; Fri, 04 Aug 2006 17:21:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G976Z-0006Fi-N2 for sip@ietf.org; Fri, 04 Aug 2006 17:21:15 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G976W-0006ok-V3 for sip@ietf.org; Fri, 04 Aug 2006 17:21:15 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 00D211E8C1F; Fri, 4 Aug 2006 14:21:11 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA915F8@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 14:21:11 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA915F8@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Fri, 4 Aug 2006 15:39:24 -0500") Message-ID: <8664h89ozc.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have no idea what you're talking about here. -Ekr "Samir Srivastava" writes: > I am busy with other stuff. > > Having bugs at other places, doesn't give us excuse to not to fix it. > Later write in details. It does expose the Calling numbers etc to the > spammers. E164 no are much more densly packed as compared to email > addresses. Do we want to design another numbering plan. See how we ran > out of IP addresses in V4 etc.... > > Thx > Samir > > > >>Again, do you have any evidence this is a problem in real life? >>There are lots of insane and dangerous things an operator can >>do. Why should we have protocol support for just this one? _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 17:47:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97U1-0006oi-FX; Fri, 04 Aug 2006 17:45:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97Tz-0006jg-Js for sip@ietf.org; Fri, 04 Aug 2006 17:45:27 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G97Ty-0003mh-BX for sip@ietf.org; Fri, 04 Aug 2006 17:45:27 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k74LjMM17924; Fri, 4 Aug 2006 17:45:22 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 16:45:21 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DA916FA@zrc2hxm2.corp.nortel.com> In-Reply-To: <8664h89ozc.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP thread-index: Aca4C/BaMOsDLUmCRFagTE64R0edYwAACuSQ From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, Spammers can learn the potential targets by tapping on the wire. We need to avoid more choices for them. If my phones keep on ringing from the spam calls, and anti-spit solution cannot figure it out. We will be left with only using with the different number/SIP URI etc. Gradually we will run out of this.=20 We should avoid the places where spammers can learn the targets. This is one bigger aspect, other issues comes from the less secure hops like call pattern tracking etc.=20 IMHO, we need cipher-suite exposed by the same notion we have TLS exposed in SIP. Refer the "Cheater Proxy Motivation" in the other email. Thx Samir=20 >I have no idea what you're talking about here. =20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 17:57:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97dz-0001l6-MI; Fri, 04 Aug 2006 17:55:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97dy-0001kz-BT for sip@ietf.org; Fri, 04 Aug 2006 17:55:46 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G97dx-0005Bm-12 for sip@ietf.org; Fri, 04 Aug 2006 17:55:46 -0400 Received: from [64.101.149.124] (mikwils2-w2k.cisco.com [64.101.149.124]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k74LvqVx013654 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Aug 2006 16:57:53 -0500 In-Reply-To: <86zmek9uj4.fsf@raman.networkresonance.com> References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <86ac6kcvuf.fsf@raman.networkresonance.com> <8DDD6590-6E4C-4E09-9BDD-C46A356B5751@softarmor.com> <86zmek9uj4.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96F8A0EF-B9AA-4BD4-8830-0FB85E68D2CB@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 16:55:41 -0500 To: EKR X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 4, 2006, at 2:21 PM, Eric Rescorla wrote: > > Again, do you have any evidence this is a problem in real life? Nope. But I have faith in human nature. People screw stuff up. > There are lots of insane and dangerous things an operator can > do. Why should we have protocol support for just this one? I'll agree that there are lots of things that need fixing. But why should we ever design protocols that don't account for the fact that people screw stuff up? This is just exactly like the "Should I keep STUNning a proxy when I have never received a STUN response from it?" argument. One point of view says "I was told by configuration that this server supports STUN, so I'm just going to keep STUNning it until it works right. I don't care if that reduces my effective throughput by 90%". Another says "Dude! That's not working. Maybe I should stop launching a DoS against myself." Now, that all said, I will agree that there are probably higher- priority places to be applying this "self-defending" principle than detecting stupid proxies that use low-grade crypto when they have alternative -- priorities like making it the crypto actually work at all. But we should keep this sort of thing in-mind at the design phase all the time. So understanding (and learning to avoid) the design-pattern that got us here would be a Very Good Thing. -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 18:05:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97m0-0000PO-0b; Fri, 04 Aug 2006 18:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97ly-0000P8-Su for sip@ietf.org; Fri, 04 Aug 2006 18:04:02 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G97lx-0006Cq-Jo for sip@ietf.org; Fri, 04 Aug 2006 18:04:02 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 0B38A1E8C1C; Fri, 4 Aug 2006 15:04:01 -0700 (PDT) To: Dean Willis Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <86ac6kcvuf.fsf@raman.networkresonance.com> <8DDD6590-6E4C-4E09-9BDD-C46A356B5751@softarmor.com> <86zmek9uj4.fsf@raman.networkresonance.com> <96F8A0EF-B9AA-4BD4-8830-0FB85E68D2CB@softarmor.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 15:04:00 -0700 In-Reply-To: <96F8A0EF-B9AA-4BD4-8830-0FB85E68D2CB@softarmor.com> (Dean Willis's message of "Fri, 4 Aug 2006 16:55:41 -0500") Message-ID: <86fygc6tv3.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > On Aug 4, 2006, at 2:21 PM, Eric Rescorla wrote: > > >> >> Again, do you have any evidence this is a problem in real life? > > Nope. But I have faith in human nature. People screw stuff up. > >> There are lots of insane and dangerous things an operator can >> do. Why should we have protocol support for just this one? > > I'll agree that there are lots of things that need fixing. > > But why should we ever design protocols that don't account for the > fact that people screw stuff up? Because every additional layer of detection creates additional complexity, and we well understand the problems of additional complexity. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 18:05:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97m7-0000Tk-RN; Fri, 04 Aug 2006 18:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97m6-0000Te-J7 for sip@ietf.org; Fri, 04 Aug 2006 18:04:10 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G97m5-0006Di-8r for sip@ietf.org; Fri, 04 Aug 2006 18:04:10 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id C4D6F1E8C21; Fri, 4 Aug 2006 15:04:08 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA916FA@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 15:04:08 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA916FA@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Fri, 4 Aug 2006 16:45:21 -0500") Message-ID: <86ejvw6tuv.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > Spammers can learn the potential targets by tapping on the wire. We need > to avoid more choices for them. If my phones keep on ringing from the > spam calls, and anti-spit solution cannot figure it out. We will be left > with only using with the different number/SIP URI etc. Gradually we will > run out of this. You do realize that people's phone numbers are basically public information and that you can buy CDs with lists of people's names and numbers, right? > IMHO, we need cipher-suite exposed by the same notion we have TLS > exposed in SIP. Refer the "Cheater Proxy Motivation" in the other email. I don't find this argument about cheating proxies at all convincing. Consider the following chain of SIP agents: Alice --- Atlanta --- Alberta --- Biloxi -- Bob Now, imagine that Alberta is a cheating proxy and wishes to use a weak cipher suite to connect to Biloxi. Because Biloxi inserts the information about what cipher suite was used, Bob is aware of the algorithms. However, he doesn't know what Alice actually wanted. Maybe Alice *wanted* those weak algorithms. On the other hand, Alice's only information about what algorithms were used comes through Alberta, so it can't tell that Alberta is cheating. Once again, the basic assumption behind SIPS security is that the proxies are trusted. Attempts to patch this without using end-to-end mechanisms seem likely to fail. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 18:05:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97m0-0000PO-0b; Fri, 04 Aug 2006 18:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97ly-0000P8-Su for sip@ietf.org; Fri, 04 Aug 2006 18:04:02 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G97lx-0006Cq-Jo for sip@ietf.org; Fri, 04 Aug 2006 18:04:02 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 0B38A1E8C1C; Fri, 4 Aug 2006 15:04:01 -0700 (PDT) To: Dean Willis Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <86ac6kcvuf.fsf@raman.networkresonance.com> <8DDD6590-6E4C-4E09-9BDD-C46A356B5751@softarmor.com> <86zmek9uj4.fsf@raman.networkresonance.com> <96F8A0EF-B9AA-4BD4-8830-0FB85E68D2CB@softarmor.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 15:04:00 -0700 In-Reply-To: <96F8A0EF-B9AA-4BD4-8830-0FB85E68D2CB@softarmor.com> (Dean Willis's message of "Fri, 4 Aug 2006 16:55:41 -0500") Message-ID: <86fygc6tv3.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > On Aug 4, 2006, at 2:21 PM, Eric Rescorla wrote: > > >> >> Again, do you have any evidence this is a problem in real life? > > Nope. But I have faith in human nature. People screw stuff up. > >> There are lots of insane and dangerous things an operator can >> do. Why should we have protocol support for just this one? > > I'll agree that there are lots of things that need fixing. > > But why should we ever design protocols that don't account for the > fact that people screw stuff up? Because every additional layer of detection creates additional complexity, and we well understand the problems of additional complexity. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 18:05:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97m7-0000Tk-RN; Fri, 04 Aug 2006 18:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97m6-0000Te-J7 for sip@ietf.org; Fri, 04 Aug 2006 18:04:10 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G97m5-0006Di-8r for sip@ietf.org; Fri, 04 Aug 2006 18:04:10 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id C4D6F1E8C21; Fri, 4 Aug 2006 15:04:08 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA916FA@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 15:04:08 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA916FA@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Fri, 4 Aug 2006 16:45:21 -0500") Message-ID: <86ejvw6tuv.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > Spammers can learn the potential targets by tapping on the wire. We need > to avoid more choices for them. If my phones keep on ringing from the > spam calls, and anti-spit solution cannot figure it out. We will be left > with only using with the different number/SIP URI etc. Gradually we will > run out of this. You do realize that people's phone numbers are basically public information and that you can buy CDs with lists of people's names and numbers, right? > IMHO, we need cipher-suite exposed by the same notion we have TLS > exposed in SIP. Refer the "Cheater Proxy Motivation" in the other email. I don't find this argument about cheating proxies at all convincing. Consider the following chain of SIP agents: Alice --- Atlanta --- Alberta --- Biloxi -- Bob Now, imagine that Alberta is a cheating proxy and wishes to use a weak cipher suite to connect to Biloxi. Because Biloxi inserts the information about what cipher suite was used, Bob is aware of the algorithms. However, he doesn't know what Alice actually wanted. Maybe Alice *wanted* those weak algorithms. On the other hand, Alice's only information about what algorithms were used comes through Alberta, so it can't tell that Alberta is cheating. Once again, the basic assumption behind SIPS security is that the proxies are trusted. Attempts to patch this without using end-to-end mechanisms seem likely to fail. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 18:40:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98Jr-0006zA-3c; Fri, 04 Aug 2006 18:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98Jo-0006z4-PX for sip@ietf.org; Fri, 04 Aug 2006 18:39:00 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G98Jn-0001ng-F1 for sip@ietf.org; Fri, 04 Aug 2006 18:39:00 -0400 Received: from [172.17.1.114] ([172.17.1.114]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k74Mbhxm015365 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Aug 2006 17:37:43 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <96F8A0EF-B9AA-4BD4-8830-0FB85E68D2CB@softarmor.com> References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <86ac6kcvuf.fsf@raman.networkresonance.com> <8DDD6590-6E4C-4E09-9BDD-C46A356B5751@softarmor.com> <86zmek9uj4.fsf@raman.networkresonance.com> <96F8A0EF-B9AA-4BD4-8830-0FB85E68D2CB@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 17:37:37 -0500 To: Dean Willis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 4, 2006, at 4:55 PM, Dean Willis wrote: > > On Aug 4, 2006, at 2:21 PM, Eric Rescorla wrote: > > >> >> Again, do you have any evidence this is a problem in real life? > > Nope. But I have faith in human nature. People screw stuff up. > >> There are lots of insane and dangerous things an operator can >> do. Why should we have protocol support for just this one? > > I'll agree that there are lots of things that need fixing. > > But why should we ever design protocols that don't account for the > fact that people screw stuff up? > > This is just exactly like the "Should I keep STUNning a proxy when > I have never received a STUN response from it?" argument. > > One point of view says "I was told by configuration that this > server supports STUN, so I'm just going to keep STUNning it until > it works right. I don't care if that reduces my effective > throughput by 90%". > > Another says "Dude! That's not working. Maybe I should stop > launching a DoS against myself." > > Now, that all said, I will agree that there are probably higher- > priority places to be applying this "self-defending" principle than > detecting stupid proxies that use low-grade crypto when they have > alternative -- priorities like making it the crypto actually work > at all. > > But we should keep this sort of thing in-mind at the design phase > all the time. So understanding (and learning to avoid) the design- > pattern that got us here would be a Very Good Thing. > Complexity breeds bugs. Complexity to work around bugs breeds new and different bugs. (Yes, I am counting misconfiguration as a kind of bug.) In general, I think we need a strong motivation that a _particular_ potential bug is much more likely and/or damaging than most others before we start writing special protocol machinery around it. (I actually don't have an opinion as to whether this particular issue meets that criteria.) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 19:02:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98el-000593-4F; Fri, 04 Aug 2006 19:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98ek-00058y-4O for sip@ietf.org; Fri, 04 Aug 2006 19:00:38 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G98ei-0003pW-Qm for sip@ietf.org; Fri, 04 Aug 2006 19:00:38 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k74N0WQ20442; Fri, 4 Aug 2006 19:00:32 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 18:00:22 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DA917E3@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP thread-index: Aca4Ee1mSqtzT+FMTCmw5jp5Vdr7fQAADN0gAAD83XAAAKbp8A== From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, =20 >You do realize that people's phone numbers are basically public >information and that you can buy CDs with lists of people's >names and numbers, right? I disagree. If I buy a privacy service from my provider, then it is not available to public. I had earlier the service from the SBC with don't list, alking caller name when callerId cannot be found to avoid blank calls. You can argue for the Don't call list also. But these don't apply in certain countries. It is big political issues to get it working there. VoIP makes it lucrative for them to call from other countries...=20 =20 Apart from spammers, what about the call pattern tracking etc? >I don't find this argument about cheating proxies at all convincing. >Consider the following chain of SIP agents: >Alice --- Atlanta --- Alberta --- Biloxi -- Bob >Now, imagine that Alberta is a cheating proxy and wishes to use >a weak cipher suite to connect to Biloxi. Because Biloxi inserts >the information about what cipher suite was used, Bob is aware >of the algorithms. However, he doesn't know what Alice actually >wanted. Maybe Alice *wanted* those weak algorithms. On the >other hand, Alice's only information about what algorithms were >used comes through Alberta, so it can't tell that Alberta is >cheating. Your argument assumes that you are not using a separate header with Alice's wish list. It assumes your intersection approach correct. Or Am I missing something. If Alberta is cheating, And Biloxi is watcher, then Biloxi can check by comparing the actual cipher-suite used at the TLS layer, cipher suite inserted in the via header, and the Alice supplied cipher-suite in a header. Biloxi can reject the request. It doesn't go any further hops. And Alice can know about this by inspecting the complete reverse channel. In the reverse channel we have the complete message trail from the via header of the request. >Once again, the basic assumption behind SIPS security is that >the proxies are trusted. Attempts to patch this without using >end-to-end mechanisms seem likely to fail. Proxies should be trusted but up-to what level. We need to consider which trust is breaking what. What about the misconfigured/buggy/bad stuff. Do you want to say good bye to CS SIP and wait till we develop pure P2P SIP ... Group what is your position ? Thx Samir _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 19:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98tQ-00035v-D4; Fri, 04 Aug 2006 19:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98tP-00035q-0L for sip@ietf.org; Fri, 04 Aug 2006 19:15:47 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G98tN-00059s-LQ for sip@ietf.org; Fri, 04 Aug 2006 19:15:46 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id C92C31E8C1C; Fri, 4 Aug 2006 16:15:44 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA917E3@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Fri, 04 Aug 2006 16:15:44 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA917E3@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Fri, 4 Aug 2006 18:00:22 -0500") Message-ID: <86ejvw5bz3.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > Hi Eric, > >>You do realize that people's phone numbers are basically public >>information and that you can buy CDs with lists of people's >>names and numbers, right? > > I disagree. If I buy a privacy service from my provider, then it is not > available to public. I had earlier the service from the SBC with don't > list, alking caller name when callerId cannot be found to avoid blank > calls. It's not purely a matter of what shows up on the caller-id screen. You can buy databases of unlisted numbers as well. > Your argument assumes that you are not using a separate header with > Alice's wish list. It assumes your intersection approach correct. Or Am > I missing something. > > If Alberta is cheating, And Biloxi is watcher, then Biloxi can check by > comparing the actual cipher-suite used at the TLS layer, cipher suite > inserted in the via header, and the Alice supplied cipher-suite in a > header. Biloxi can reject the request. It doesn't go any further hops. > And Alice can know about this by inspecting the complete reverse > channel. In the reverse channel we have the complete message trail from > the via header of the request. The proxy in the middle just changes the headers. >>Once again, the basic assumption behind SIPS security is that >>the proxies are trusted. Attempts to patch this without using >>end-to-end mechanisms seem likely to fail. > > Proxies should be trusted but up-to what level. We need to consider > which trust is breaking what. What about the misconfigured/buggy/bad > stuff. What about it? As I stated previously, there are any number of ways for such a proxy to screw up. > Do you want to say good bye to CS SIP and wait till we develop > pure P2P SIP ... Group what is your position ? If you want to do P2P SIP, then you better find some way to get an end-to-end channel to the peer. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 20:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ACD-0003El-6S; Fri, 04 Aug 2006 20:39:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ACB-0003Ef-HQ for sip@ietf.org; Fri, 04 Aug 2006 20:39:15 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9AC9-0007OX-8R for sip@ietf.org; Fri, 04 Aug 2006 20:39:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k750d8Y07384; Fri, 4 Aug 2006 20:39:08 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 19:39:07 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DA9182E@zrc2hxm2.corp.nortel.com> In-Reply-To: <86ejvw5bz3.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP thread-index: Aca4G/BVKCIgrhr5QWqpMJBLwKXZsAACBiBg From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, > It's not purely a matter of what shows up on the caller-id > screen. You can buy databases of unlisted numbers as well. >=20 It's like email spammers selling their attended email addresses. I don't want to comment on the legality aspects of this here. =20 > The proxy in the middle just changes the headers. This header should be part of hash computations like used in Identity. So any middle-man tampering can be caught. Though it assumes that UAS is most trustworthy. Providers providing the services (making money) have more reasons to become cheater. End users don't have this motivation. =20 > What about it? As I stated previously, there are any number of > ways for such a proxy to screw up. My only argument here is that bugs at other places are no excuse for not addressing the issues which have a solution on the table. If proxy is generating the bad random numbers etc, then I *WISH* my IDS/IPS should catch it. People might attack on these stuff when they have other bigger issues sorted out. Thx Samir _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 21:25:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9At1-000697-CC; Fri, 04 Aug 2006 21:23:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Asz-000692-Sd for sip@ietf.org; Fri, 04 Aug 2006 21:23:29 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Asx-0000LQ-Iq for sip@ietf.org; Fri, 04 Aug 2006 21:23:29 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A318052C; Fri, 04 Aug 2006 21:23:36 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" , "'David R Oran'" Subject: RE: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 21:23:26 -0400 Message-ID: <066801c6b82d$c021af70$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca3w6paFiBNcwdwTbie28NA1gamRgAQstOAAAifZdA= In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA91621@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I hate to jump in on this conversation without knowing the full context, but since you're evoking the "it's a real world problem" argument: what makes you think as a request crosses a provider chain that the Via's from every previous hop will make it the whole way through unscathed? Via's rarely survive a multi-provider crossing in the real world, I believe. And how do you prevent some proxy simply overwriting the security-level header in the request/response so the UAC thinks everything is ok? I wonder what proxy could do that... I must be missing something very basic. Is the security-level field signed and verified somehow by both ends? And you also assume 2 proxies in the middle don't collude? It's not that unlikely. -hadriel > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: Friday, August 04, 2006 4:51 PM > To: David R Oran > Cc: sip@ietf.org > Subject: RE: [Sip] Ciphersuites in SIP > > > Dave, I respectfully disagree here with you. > In the real life scenarios, even the mission critical stuff have hit the > bugs, where lot of redundancy is employed. We designed the alternate > routes, form of proxy servers etc for this... > The problem here is misconfigured/cheater proxy is making the system > totally unsecure. > Consider the following case for the cheater proxy > > > UAC ----> P1 ------> P2 -------> P3 ..... > > > Proxy P1 services to the UAC with the all known latest ciphersuites say > AES256 for the current state. But provider of Proxy P2 charges > differently to P1 for AES256. And As AES128 current mandatory > cipher-suite, it will say let us downgrade it to complete the request. > Some old may downgrade it to 3DES. If we don't have a cipher-suites > exposed to SIP, users cannot know what is done by the providers... > > Thx > Samir > > > > >You mean we forgot these in the requirements document: > > >Req 1A: Proxies MUST NOT have any bugs. > >Req 1B: Proxies MUST NOT be misconfigured by administrators > > >Ah, that makes me feel better. > > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 04 21:49:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9BG8-0002E0-AG; Fri, 04 Aug 2006 21:47:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9BG6-0002CS-HB for sip@ietf.org; Fri, 04 Aug 2006 21:47:22 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9BG5-00084D-6K for sip@ietf.org; Fri, 04 Aug 2006 21:47:22 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A8A9059C; Fri, 04 Aug 2006 21:47:21 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" , "'EKR'" Subject: RE: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 21:47:11 -0400 Message-ID: <066c01c6b831$119edcd0$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca4Ee1mSqtzT+FMTCmw5jp5Vdr7fQAADN0gAAD83XAAAKbp8AAFYo3A In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA917E3@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > > >You do realize that people's phone numbers are basically public > >information and that you can buy CDs with lists of people's > >names and numbers, right? > > I disagree. If I buy a privacy service from my provider, then it is not > available to public. I had earlier the service from the SBC with don't > list, alking caller name when callerId cannot be found to avoid blank > calls. Spammers don't care about you. If your number is not listed on any database (fat chance of that, BTW), they won't call you. That doesn't stop them from spamming. Their goal is broad coverage, not a specific individual. If no one's number was in a database, then few people would be able to communicate. And spamming would still be possible, since they can simply war-dial/number-scan - the issue is how to detect+stop them, not hope you keep lists of fixed-length numbers from them. IMO, preventing Spam is an orthogonal issue to ensuring end-end eavesdropping protection, authentication, etc. > If Alberta is cheating, And Biloxi is watcher, then Biloxi can check by > comparing the actual cipher-suite used at the TLS layer, cipher suite > inserted in the via header, and the Alice supplied cipher-suite in a > header. Biloxi can reject the request. It doesn't go any further hops. You're assuming Biloxi will do this, because you're assuming it has an incentive to reject the request. It's quite the opposite. Biloxi has a relationship with Alberta. Biloxi makes money from Alberta. If Alberta doesn't want to use a ciphersuite of some UAC's choosing, Biloxi's going to agree with Alberta, not the UAC. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 22:25:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9BpK-0008GJ-3V; Fri, 04 Aug 2006 22:23:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9BpI-0008F2-IT for sip@ietf.org; Fri, 04 Aug 2006 22:23:44 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9BpG-0005eL-9T for sip@ietf.org; Fri, 04 Aug 2006 22:23:44 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A133059C; Fri, 04 Aug 2006 22:23:47 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" Subject: RE: [Sip] Ciphersuites in SIP Date: Fri, 4 Aug 2006 22:23:37 -0400 Message-ID: <066d01c6b836$2891daf0$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca4G/BVKCIgrhr5QWqpMJBLwKXZsAACBiBgAAOh9GA= In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA9182E@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > > It's like email spammers selling their attended email addresses. I don't > want to comment on the legality aspects of this here. Not to belabor the point of spamming, because I really don't think that's the benefit of assured hop-by-hop encrypt, but email spamming needs lists because the target name@domain is so variable. (yes, I know they probe too) Spamming e164's is far easier without a list, because the target is a very finite set: fixed-length integers of specific pattern ranges. What's worse, they're generally allocated in blocks, so the range is not very big and the domain can be inferred. If we can get broad use of real alphanum sip uri's, then we're back to lists becoming more useful. Anyway... back on topic. > > The proxy in the middle just changes the headers. > > This header should be part of hash computations like used in Identity. > So any middle-man tampering can be caught. Though it assumes that UAS is > most trustworthy. Providers providing the services (making money) have > more reasons to become cheater. End users don't have this motivation. But you just pointed out the flaw. Providers have an incentive to "cheat": they want the call to succeed so they get paid. So imagine 2 providers in the middle. They decide to connect over an L2 VPN through a carrier, which they've been told is "secure". A request comes through that says "use TLS". Do you think they're going to reject it? No. Then they find out some Via gave them away. So do you think they're going to set their proxies to remove/modify their Via's, or start using TLS instead? My guess is the former. Obviously some providers will do the right thing. But those are the ones that will probably use TLS or IPSec anyway and you don't need this mechanism to defend against. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 04 23:25:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Ckw-0001vC-8P; Fri, 04 Aug 2006 23:23:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Cku-0001tp-T1 for sip@ietf.org; Fri, 04 Aug 2006 23:23:16 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Ckt-0001ve-LA for sip@ietf.org; Fri, 04 Aug 2006 23:23:16 -0400 Received: from [71.240.232.162] (helo=JMHLap3.stevecrocker.com) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1G9Ckt-00007Y-50 for sip@ietf.org; Fri, 04 Aug 2006 23:23:15 -0400 Message-Id: <7.0.1.0.0.20060804231954.03f01668@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 04 Aug 2006 23:23:12 -0400 To: sip@ietf.org From: "Joel M. Halpern" Subject: RE: [Sip] Ciphersuites in SIP In-Reply-To: <066d01c6b836$2891daf0$6601a8c0@acmepacket.com> References: <62B9B0847CC47543B6B3B5E26BD268E60DA9182E@zrc2hxm2.corp.nortel.com> <066d01c6b836$2891daf0$6601a8c0@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112024907aab0a2d16042346993dc0fcd482a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.240.232.162 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In fact, what this example points out is that having the end user request that two intermediaries use TLS is actually making the wrong request. 1) If the user really wants to ensure that the call is protected on every hop, he should arrange for end-to-end protection. 2) If the user wants to request that proxies use security of appropriate strength, that is what should be requested. The user ought not actually care whether the proxies used TLS, IPSec, or a new and different technique that is just as secure. And, as has been pointed out, colluding pairs of proxies can lie about almost anything unless one uses end-to-end mechanisms. So providing ways for one of a pair of proxies to check the other seems to address a small concern. I think that the concern over excessive complexity for a solution to a small piece of a problem is well taken. Yours, Joel M. Halpern At 10:23 PM 8/4/2006, Hadriel Kaplan wrote: >So imagine 2 providers in the middle. They decide to connect over an L2 VPN >through a carrier, which they've been told is "secure". A request comes >through that says "use TLS". Do you think they're going to reject it? No. >Then they find out some Via gave them away. So do you think they're going >to set their proxies to remove/modify their Via's, or start using TLS >instead? My guess is the former. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 05 01:07:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9EM0-0007Q8-Ke; Sat, 05 Aug 2006 01:05:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ELy-0007Mi-IJ for sip@ietf.org; Sat, 05 Aug 2006 01:05:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9DGP-0004QR-Un for sip@ietf.org; Fri, 04 Aug 2006 23:55:50 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G9D6X-00082A-Gi for sip@ietf.org; Fri, 04 Aug 2006 23:45:38 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A45F0624; Fri, 04 Aug 2006 23:45:35 -0400 From: "Hadriel Kaplan" To: Subject: RE: [Sip] SIP Security mechanism? Date: Fri, 4 Aug 2006 23:45:24 -0400 Message-ID: <067801c6b841$95718e30$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca3YJ53H8ow8rqnRxKjUAnkdg0p7gAHJaig In-Reply-To: <1154652847.2521.30.camel@dimension.cornfed.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > Sent: Thursday, August 03, 2006 8:54 PM > > Agreed, but end-to-end encryption of the bodies is also hard given the > basic architecture of SIP and valuable. Yeah, but whether it's valuable or not is the question. If it doesn't authenticate, then it's not end-to-end. Because I guarantee you if it becomes popular then certain boxes will terminate it, view and/or modify the body, and re-encrypt. They won't do it for malicious purposes (well, some people think what they do is evil, but that's another story). But my point is any box could do that; in fact every box could do that, and the 2 ends would never know. > S/MIME does that job but there > is the problem of managing certs (spearmint for me thanks). (Speermint is a different WG. ;) I actually don't think S/MIME's failure was because of a PKI. Well, maybe that was part of its initial downfall, but now it's too late. Too many middle-boxes want to see SDP, and some of them need to modify it. It's not that the vendors who make them _want_ to do that, it's because the people who buy them want them to do it, to perform certain functions. It's a market decision, not up to a standards body. (BTW, I'm not just talking about SBCs here) If you want to use those people's services, you have to let them see SDP. If you don't, then send your SIP direct end-to-end. And when you do that you might as well use TLS instead of SDP encryption. If you don't send it direct, then you won't know if anything in between has modified the data or not, because you're not authenticating it. > > I think you said the benefit of this is "perhaps encryption would become > > more pervasive". TLS provides you that (and more), yet it's not > pervasive. > > It's not end-2-end, but then neither is your mechanism ultimately. > > This proposal could be made end-to-end if some form of authentication > were built on top of it. That cannot be said of TLS unless S/MIME or > something like this is used in conjunction with it. Yup, I know. My point was it's the authentication that's the key. (pun intended) Without that it's not worth it, IMHO. Actually, even with that I think its scope is limited. You are making an assumption that the ends are more trustworthy than the middle. The guys who own the middle see it the other way around. The guys who own a middle and a population of ends trust the middle the most, their ends next, and the rest of the internet the least. (for example, an Enterprise or a home phone provider) But that's just my warped view. I'm one of the "bad" guys. ;) > Your discussion is actually crystallizing the thought that perhaps > encryption and authentication should be separated architecturally. This > would allow for various types of encryption and various types of > authentication to be used as required for a given application. This > would also allow for situations where authentication is not required but > encryption is needed to be implemented separately from those situations > that require both. Authentication without encryption has value. And encryption without authentication has value too in some cases. (media is actually a decent example of this I think) But for MIME attachments in SIP? Don't get me wrong, I'm fine with better-than-nothing security mechanisms - I just think there needs to be an issue worth addressing, and worth the cost/trouble to do it. In my mind what you're proposing would end up being close to hop-by-hop in the real world (mine of course), and at that point I'd rather just use TLS. What we need is to figure out how to get TLS used broadly. > I can think of situations where encryption with essentially implicit > authentication are possible. Consider a military wireless network for > example. In such a case, the underlying signal in space provides > implicit authentication but there can never be enough layers of > encryption. God I sure hope they don't think the underlying signal provides all the authentication they need. And their needs are quite a bit more than most people's. I don't mean we couldn't all do better with their level of paranoia, just that it's not free, and different markets tend to have a different cost burden they're willing to live with for security. > One might argue that if you're going to go to the trouble > to encrypt, why not do authentication? I think the problem is just what > we've seen, managing central repositories of cert information is hard in > practice. I think the problem is slightly different. The problem is varying, but one of the big ones I think is its just not easy to put and manage certs on every PC/phone (at least certs you can trust). How frequently is TLS mutual authentication performed? Most of the time certs are just on servers, and it takes a higher-level authentication for the server to authenticate the client. For example a login password/challenge (shared secret) through the application riding on TLS. > Hope I'm not rambling on too much now... I can ramble with the best of them. :) -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 05 16:33:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Snn-0001Fk-3Q; Sat, 05 Aug 2006 16:31:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Snl-0001Ff-7p for sip@ietf.org; Sat, 05 Aug 2006 16:31:17 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Snj-0004Tn-Sw for sip@ietf.org; Sat, 05 Aug 2006 16:31:17 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.6/IER-o) with ESMTP id k75KVFA7010877 for ; Sat, 5 Aug 2006 15:31:15 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 5 Aug 2006 15:31:15 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 5 Aug 2006 22:31:13 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 5 Aug 2006 22:31:13 +0200 Message-ID: <5D1A7985295922448D5550C94DE291801E50FD@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continuation of WGLC on draft-ietf-sip-gruu-10 Thread-Index: Aca4t6jzb0cIdg3jQp2xn/3iF5Fd1g== From: "Drage, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 05 Aug 2006 20:31:13.0915 (UTC) FILETIME=[186C1CB0:01C6B8CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Sip] Continuation of WGLC on draft-ietf-sip-gruu-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Working Group Last Call ----------------------- Jonathan has just published http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-10.txt which should take into account all the major comments that have been so far received on this document. Having initiated WGLC on this document on 13th January 2004, and revised that WGLC on 5th July 2004 and 26th October 2005 we would really like to reach a final conclusion of this WGLC.=20 Therefore please review the document and submit your WGLC comments within two weeks, ie. By the 21st August 2006. Process ------- In addition to an open invitation for review by all members of the working group, we will be soliciting full review by a number of experts who we believe will provide a good and complete understanding of the issues and problems, if any, with the document. If you consider you should be part of this list this please contact the WG chairs. The WG chairs will compile all submitted comments into a single review document which will be discussed on the conference call below. Please therefore submit your comments (to the SIP WG list and the WG chairs) with information under the following headings for each comment: - location in document - nature of comment (editorial, minor technical, critical error, absolute show stopper - use your judgement on this) - comment - proposed fix We intend to have a conference call for reviewers to conclude on the quality of the document on Monday 4th September at: 8:00 am Pacific Time 10:00 am Central US Time 11:00 am Eastern US Time 4:00 pm UK 5:00 pm Central European Summer Time Bridge details as follows: Access Phone Number: 8007718734=20 International Access Phone Number: +1 6477233953=20 7-Digit Access Code: 5776249=20 While this call is open to all WG members, we would expect only people who have reviewed the document on this conference call. For details of the process please see previous communication. Note that the above does include those reviewers who reviewed the document and had no comments - if you are in this class, please report it. Regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 05 22:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Yb3-0002MY-1E; Sat, 05 Aug 2006 22:42:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Yb1-0002MK-7D for sip@ietf.org; Sat, 05 Aug 2006 22:42:31 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Yaz-0007ti-Uu for sip@ietf.org; Sat, 05 Aug 2006 22:42:31 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.6/IER-o) with ESMTP id k762gT18025549; Sat, 5 Aug 2006 21:42:29 -0500 (CDT) Received: from [135.244.0.108] (vkg.lra2.lucent.com [135.244.0.108]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k762gMv04888; Sat, 5 Aug 2006 21:42:26 -0500 (CDT) Message-ID: <44FE358A.4080401@lucent.com> Date: Tue, 05 Sep 2006 21:42:18 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: EKR Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA917E3@zrc2hxm2.corp.nortel.com> <86ejvw5bz3.fsf@raman.networkresonance.com> In-Reply-To: <86ejvw5bz3.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: > If you want to do P2P SIP, then you better find some way to get > an end-to-end channel to the peer. sipsec URI? - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 05 22:49:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9YgJ-0005Wr-0z; Sat, 05 Aug 2006 22:47:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9YgH-0005UX-Mu for sip@ietf.org; Sat, 05 Aug 2006 22:47:57 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9YgG-0008Kf-ED for sip@ietf.org; Sat, 05 Aug 2006 22:47:57 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 90DFB1E8C1C; Sat, 5 Aug 2006 19:47:55 -0700 (PDT) To: "Vijay K. Gurbani" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA917E3@zrc2hxm2.corp.nortel.com> <86ejvw5bz3.fsf@raman.networkresonance.com> <44FE358A.4080401@lucent.com> From: Eric Rescorla Date: Sat, 05 Aug 2006 19:47:55 -0700 In-Reply-To: <44FE358A.4080401@lucent.com> (Vijay K. Gurbani's message of "Tue, 05 Sep 2006 21:42:18 -0500") Message-ID: <86wt9m37hg.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Vijay K. Gurbani" writes: > Eric Rescorla wrote: >> If you want to do P2P SIP, then you better find some way to get >> an end-to-end channel to the peer. > > sipsec URI? Huh? -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 05 22:52:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9YjK-0007XL-0S; Sat, 05 Aug 2006 22:51:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9YjI-0007XE-KO for sip@ietf.org; Sat, 05 Aug 2006 22:51:04 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9YjH-0008UT-Cc for sip@ietf.org; Sat, 05 Aug 2006 22:51:04 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.6/IER-o) with ESMTP id k762p2LB027832; Sat, 5 Aug 2006 21:51:03 -0500 (CDT) Received: from [135.244.0.108] (vkg.lra2.lucent.com [135.244.0.108]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k762p2v06553; Sat, 5 Aug 2006 21:51:02 -0500 (CDT) Message-ID: <44FE3792.3020105@lucent.com> Date: Tue, 05 Sep 2006 21:50:58 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: EKR Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA917E3@zrc2hxm2.corp.nortel.com> <86ejvw5bz3.fsf@raman.networkresonance.com> <44FE358A.4080401@lucent.com> <86wt9m37hg.fsf@raman.networkresonance.com> In-Reply-To: <86wt9m37hg.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: > Huh? Sorry; we had discussed this in the SIP security ad-hoc in Montreal. Establishing a security tunnel across proxies to exchange certs end-to-end: http://www.ietf.org/internet-drafts/draft-gurbani-sip-sipsec-00.txt Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 01:02:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9xDu-0005DJ-PL; Mon, 07 Aug 2006 01:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9xD8-0004vz-Bh for sip@ietf.org; Mon, 07 Aug 2006 00:59:30 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9xAN-0005ed-9I for sip@ietf.org; Mon, 07 Aug 2006 00:56:40 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Mon, 7 Aug 2006 06:56:37 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Aug 2006 06:56:37 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A6DE@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: maltarai@cisco.com, sanjsinh@cisco.com, jdrosen@cisco.com, sip@ietf.org Subject: AW: [Sip] updated acr code draft Date: Mon, 7 Aug 2006 06:56:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The UAC either should include the identity in the From header instead = of anonymous or don't call again if the user still wants to be = anonymous. The UAS should close the transactions. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com]=20 > Gesendet: Freitag, 4. August 2006 16:13 > An: Jesske, Roland; Sanjay Sinha (sanjsinh); Jonathan=20 > Rosenberg (jdrosen); sip@ietf.org > Betreff: RE: [Sip] updated acr code draft >=20 >=20 >=20 > The identity in the From header in not the correct party=20 > after the xfer is complete! I still don't see an answer to=20 > what should the UAC > do when it gets the 433 response, or what the UAS should do=20 > after it send the 433, basically how does that response=20 > impact the INVITE dialog. >=20 > Thanks, >=20 > Mo=20 >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > Sent: Friday, August 04, 2006 4:14 AM > To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh);=20 > Jonathan Rosenberg (jdrosen); sip@ietf.org > Subject: AW: [Sip] updated acr code draft >=20 > There is a difference between an unavailable identity and a=20 > anonymous identity so that the endpoint can decide. > As a wrote before the From header is a mandatory header. So=20 > there must an identity in.=20 >=20 > In which scenario this early attended transfer could appear=20 > is this also a interworking case or a pure SIP case? >=20 > What is with the identity I'm registering with? >=20 >=20 > BR >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] > > Gesendet: Donnerstag, 3. August 2006 16:22 > > An: Sanjay Sinha (sanjsinh); Jesske, Roland; Jonathan Rosenberg=20 > > (jdrosen); sip@ietf.org > > Cc: Mohammad Al-Taraireh (maltarai) > > Betreff: RE: [Sip] updated acr code draft > >=20 > >=20 > >=20 > > Another case is a early attended transfer. For example the transfer = > > target will get an INVITE without caller id blocking and then an=20 > > UPDATE after the xfer with caller id blocking to change the=20 > display.=20 > > If there is a policy on the endpoint to reject anonymous=20 > calls, what=20 > > should the do in this case? which the question below "what does 433 = > > mean for mid call UPDATE or reINVITE?" > >=20 > > Thanks, > >=20 > > Mo > >=20 > > -----Original Message----- > > From: Sanjay Sinha (sanjsinh) > > Sent: Thursday, August 03, 2006 9:57 AM > > To: Jesske, R; Jonathan Rosenberg (jdrosen); sip@ietf.org > > Subject: RE: [Sip] updated acr code draft > >=20 > > Scenario is PSTN-SIP interworking. For some cases, display=20 > IE is not=20 > > available in SETUP because some TCAP query is required.=20 > When the query=20 > > is complete, switch sends display IE in a FACILITY message. From=20 > > header is mandatory in INVITE, but calling name and number=20 > is not. So=20 > > Invite is sent without caller-identity which is later=20 > updated with an=20 > > UPDATE/INFO, when the UA gets FACILITY with display information. > >=20 > > Thanks > > Sanjay.=20 > >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: Thursday, August 03, 2006 1:52 AM > > To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen);=20 > > sip@ietf.org > > Subject: AW: [Sip] updated acr code draft > >=20 > > The ACR service itself reacts only on identities that are=20 > put anonymus=20 > > by the user or on behalf on the user. > > So if the restriction is based on other reasons ACR will=20 > not terminate=20 > > the call. > >=20 > > My question to your scenario is in which case an identity is not=20 > > available in an INVITE. The From header is an mandatory=20 > header so the=20 > > >From Header has have an user identity. Or not? > >=20 > > The P-Asserted-Identity is set by an trusted network entity that is = > > aware of the user sending that request. > >=20 > > Best Regards > >=20 > > Roland > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > > Gesendet: Mittwoch, 2. August 2006 17:32 > > > An: Jonathan Rosenberg (jdrosen); IETF SIP List > > > Betreff: RE: [Sip] updated acr code draft > > >=20 > > >=20 > > > What about the case in which caller information is not=20 > available at=20 > > > the time INVITE is sent to establish a call, but is=20 > available later=20 > > > and an UPDATE/INFO is sent by UAC to update the caller-id > > information. > > > If UAS rejects UPDATE/INFO with 433, what does it mean for > > the Invite > > > dialog. > > > Should that also be terminated as a result of ACR? > > >=20 > > > Thanks > > > Sanjay > > >=20 > > > -----Original Message----- > > > From: Jonathan Rosenberg (jdrosen) > > > Sent: Monday, July 31, 2006 4:31 PM > > > To: IETF SIP List > > > Subject: [Sip] updated acr code draft > > >=20 > > > I've submitted a minor update to the ACR code draft. Until > > it appears, > > > you can pick it up at: > > >=20 > > > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt > > >=20 > > > the changes are: > > >=20 > > > * replaced P-Asserted-ID with P-Asserted-Identity > > >=20 > > > * added to security considerations section, consideration for=20 > > > anonymizers in the network. Namely, don't retry request on > > receipt of > > > 433 unless explicitly configured to do so by user > > >=20 > > >=20 > > > Thanks, > > > Jonathan R. > > > --=20 > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Cisco Fellow Parsippany, NJ=20 > > > 07054-2711 > > > Cisco Systems > > > jdrosen@cisco.com FAX: =20 > (973) 952-5050 > > > http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > > http://www.cisco.com > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.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 = > > > sipping@ietf.org for new developments on the application of sip > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.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 = > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.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://www1.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 > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 07 10:13:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA5pb-0005MV-L1; Mon, 07 Aug 2006 10:11:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA5pZ-0005ML-SS for sip@ietf.org; Mon, 07 Aug 2006 10:11:45 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA5pX-000067-Ht for sip@ietf.org; Mon, 07 Aug 2006 10:11:45 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k77EBbKX010067; Mon, 7 Aug 2006 09:11:37 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k77EBbm15882; Mon, 7 Aug 2006 09:11:37 -0500 (CDT) Message-ID: <44D74A19.5050409@lucent.com> Date: Mon, 07 Aug 2006 09:11:37 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] comments on draft-ietf-sip-connect-reuse-05 References: <44ADE168.7050309@cisco.com> <44AF59A8.1000304@lucent.com> <77482B40-90DF-43A7-BC76-07EA1AF05C52@cisco.com> In-Reply-To: <77482B40-90DF-43A7-BC76-07EA1AF05C52@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1162389187==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1162389187== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060306040305020305090004" This is a cryptographically signed message in MIME format. --------------ms060306040305020305090004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > Big question ... If the proxies always did this regardless of if > there was an alias tag in the via or not, would everything work? I > could not find something that did not work but I could easily be > missing the obvious. I do note that alias indicates you want a long > lived connection but everyone always wants to be long lived so we > could just assume that. Cullen: If the alias parameter was not in the Via header, I suspect things will work just as well assuming that the sender of the request leaves its connection open beyond the transaction/dialog lifetime (while majority of proxies may, not all do). However, I lean towards making the intent of a feature more explicit, if possible, in the signaling. So, a proxy receiving a request with an "alias" parameter can deterministically know the behavior of its peer. All things being equal, I would rather leave the parameter in there. > I don't think this works from some TLS situations. [...] > (PS. I think I have mentioned this on several different versions of > this document - let me know if I am not making any sense) Thanks for being persistant with this example; yes, it is in my list of things to close down in the next rev of the draft. I am spending this week rev'ing the draft, so I suspect that I will address this question successfully, or failing that, open up a dialog on the mailing list about it. > Seems like we should be more blunt up front that this does not work > for TCP and can only be used for TLS > > Few trivial things ... Noted; will wordsmith them in. Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms060306040305020305090004 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIlPjCC Ch4wggkGoAMCAQICCh6WhFwAAAAACpUwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA2MDYyNjE2MTI1M1oXDTA4MDYyNjE2MjI1M1owQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsCokOtoH/zOzgQOoH5wBSXpXbUvvzpuM4u5y pSGFeBeTKuTzew3EvxcAB7r1gHMNTgMXvCaLs6o9VUkoQQKaWGNXXZqLkkkCbHr+KD82IAmO OXqKJtYvNOlraQahXTKlrG6+oT6VFa9BIza/uSZ2DKPcscoVSBBEmbC8Zoh7lH7/sl6BveFg j1e0rTrC4ml90zVnxFnz2ARTExawUx7hyVKLmWy84egc6yDh7sc5B+6NbJv1GdSJOASJbNcL LvxihE2wgD71nhRtWzMAdzg4nsd8yI9bshUGqYbiiKC9GrV9NN7AJ0WsLQtLYs+1dcuMNXlL caEyIxTCcmZwnYNsowIDAQABo4IGpDCCBqAwHQYDVR0OBBYEFNNWvr2U2hSbKzlP8W4ih6m5 pjNMMIH+BgNVHSMEgfYwgfOAFISfQVWcEIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJ KoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UE CBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBU ZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1 Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPy LGQBAQQFFgN2a2cwFwYKCZImiZPyLGQBLAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIF oDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcD BzCCAncGCCsGAQUFBwEBBIICaTCCAmUwgc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNl YXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZp Y2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAx LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZp Y2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHM BggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRp ZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIIC gTCCAn0wgdaggdOggdCGgc1sZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2Nu PUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVy ZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0 aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDovL2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0 aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxp c3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB 0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRl Y2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRp b24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlz dDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqG SIb3DQEBBQUAA4IBAQCZpf5cNwck4S9qjuX6Hfo+FWFtWTIPMPGVwsMVYz97hmEPKzxA8zMP aO0Z9+FD75ZBc2GkZsHQVGbAjrqkeOSfdt5MF2Qex0Z6o4jw0U/w2/EzGLogdBp7jC1DJ6Tm TqBLqRnjPsPs2NGazbTKmEoJX2isQOBUZyfzM44uCyVEY6Sk6FGqR7RDDCvr7VZvo/28d6at U9ueIa6rtdk+AxlXyqsJ6GBUL+ZBNJQ58L9xqynzPmikjntfM1TEhvkOATXLJ7wqf6ao4lKk gg5cqOxHPVMAje5K9f8V9hdUOtc9MNCR9nyTo8qNzMNyh8FR+1/qxFDtiJG5l6EArgfl2OGr MIIKHjCCCQagAwIBAgIKHpaEXAAAAAAKlTANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3 DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5l dyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5v bG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZp Y2VzIDEwHhcNMDYwNjI2MTYxMjUzWhcNMDgwNjI2MTYyMjUzWjBBMR0wGwYJKoZIhvcNAQkB Fg52a2dAbHVjZW50LmNvbTEgMB4GA1UEAxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwKiQ62gf/M7OBA6gfnAFJeldtS+/Om4zi 7nKlIYV4F5Mq5PN7DcS/FwAHuvWAcw1OAxe8Jouzqj1VSShBAppYY1ddmouSSQJsev4oPzYg CY45eoom1i806WtpBqFdMqWsbr6hPpUVr0EjNr+5JnYMo9yxyhVIEESZsLxmiHuUfv+yXoG9 4WCPV7StOsLiaX3TNWfEWfPYBFMTFrBTHuHJUouZbLzh6BzrIOHuxzkH7o1sm/UZ1Ik4BIls 1wsu/GKETbCAPvWeFG1bMwB3ODiex3zIj1uyFQaphuKIoL0atX003sAnRawtC0tiz7V1y4w1 eUtxoTIjFMJyZnCdg2yjAgMBAAGjggakMIIGoDAdBgNVHQ4EFgQU01a+vZTaFJsrOU/xbiKH qbmmM0wwgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcswgcgxJTAj BgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYD VQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50 IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkGA1UEAxMi THVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTATBgoJkiaJ k/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4QgEBBAQD AgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQGCCsGAQUF BwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8vbGRhcC11 c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1Y2VudC5j b20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUy MDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRp ZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2Jp bmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKKBgNVHR8E ggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0 ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25B dXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmlj YXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9u bGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHU oIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIw VGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2VydGlmaWNh dGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25s aXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJ KoZIhvcNAQEFBQADggEBAJml/lw3ByThL2qO5fod+j4VYW1ZMg8w8ZXCwxVjP3uGYQ8rPEDz Mw9o7Rn34UPvlkFzYaRmwdBUZsCOuqR45J923kwXZB7HRnqjiPDRT/Db8TMYuiB0GnuMLUMn pOZOoEupGeM+w+zY0ZrNtMqYSglfaKxA4FRnJ/Mzji4LJURjpKToUapHtEMMK+vtVm+j/bx3 pq1T254hrqu12T4DGVfKqwnoYFQv5kE0lDnwv3GrKfM+aKSOe18zVMSG+Q4BNcsnvCp/pqji UqSCDlyo7Ec9UwCN7kr1/xX2F1Q61z0w0JH2fJOjyo3Mw3KHwVH7X+rEUO2IkbmXoQCuB+XY 4aswghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUwIwYJKoZI hvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMK TmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNo bm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2Vu dCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcNMTAxMjA2 MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNvbTELMAkG A1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBIaWxsMRww GgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVjaG5vbG9n aWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+JXW72361 5PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHEx5xRWAiO NeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJE3BGQTOX 0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46CZQsibysV efigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMBAAGjggz0 MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4hS09K38sw CwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/hK1C+quh9 NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNl bnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVy cmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRo b3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCBxoaBw2xk YXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9n aWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMs bz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2Jq ZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6Ly9sZGFw LXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9v dCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQu Y29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4dGVybmFs Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2 b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhv cml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlv biUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0 O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcqggceg gcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNo bm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/bGRhcDov L2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJv b3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50 LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNz PWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJpdHkubHVj ZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYBBQUHMAKG gbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hu b2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0 aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNz PWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xkYXAtdXN3 ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIw QXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/ Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0 aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZp Y2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5 P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYBBQUHMAKG gbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRl Y2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhv cml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNs YXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDovL2xkYXAt ZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUy MEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29t P2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNv bS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRp ZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggrBgEFBQcw AoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9s b2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGll cyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1j ZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNlY3VyaXR5 Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5UrdsB2nOxTre kCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82gm7eZee7 lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13h4tgCPG3 WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biRZr61dWmQ WajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb1QUPqg8/ g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCBEowggRGAgEBMIHBMIGyMSUwIwYJKoZI hvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMK TmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNo bm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2Vy dmljZXMgMQIKHpaEXAAAAAAKlTAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA4MDcxNDExMzdaMCMGCSqGSIb3DQEJBDEWBBTy yl1uTCjhQQ7eQurcy9XUyUbvrDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB0gYJ KwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQu Y29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5 IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBU ZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKHpaEXAAAAAAKlTCB1AYLKoZI hvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5j b20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkg SGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVjZW50IFRl Y2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoeloRcAAAAAAqVMA0GCSqGSIb3 DQEBAQUABIIBABm56s1HyEQH0dscJe3S5vbiOnnt+WVhwzsehFDw6Ad4nFOLYtc174W6jWfN 5E4lzLCaSM0/j+kuVgzdGOQmivc4jy5NOCaNpKjmvcYr+PqsGsCoVHDQvGGkyyyV3dqdAe/D bZUqY1GX+QIXyL9c4+OysIZxSMDuO3bL3wLD6OLrntg8zwfirIT52RLRtqp7lgleSkmkT1XM 8vnFhun5CxKlfxRBMn4t0j3lQj37Lzzx1pZbBOQVKAub9tuRyu3zS91LFs/XAl+ypb+cfqb2 H/rdLSpUlptkZaUYXsG2ARacHQ/vAojy2qGd05ael10JEWrP336jAYuTVjbRTs7UupEAAAAA AAA= --------------ms060306040305020305090004-- --===============1162389187== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============1162389187==-- From sip-bounces@ietf.org Mon Aug 07 14:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9OQ-0007t8-9s; Mon, 07 Aug 2006 13:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9OO-0007t1-NZ for sip@ietf.org; Mon, 07 Aug 2006 13:59:56 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA9OM-0005N3-DU for sip@ietf.org; Mon, 07 Aug 2006 13:59:56 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id AFA50690; Mon, 07 Aug 2006 14:00:05 -0400 From: "Hadriel Kaplan" To: "'David R Oran'" Subject: RE: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Mon, 7 Aug 2006 13:59:53 -0400 Message-ID: <079e01c6ba4b$49058590$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca2QB7yMwhZc8HsTomTivxChtS2swD/fC0w In-Reply-To: <9CF181E9-98AA-4B12-A6A2-964D9C4BC478@cisco.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'Cullen Jennings' , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Wednesday, August 02, 2006 10:30 AM > > On Aug 1, 2006, at 7:19 PM, Hadriel Kaplan wrote: > > > So then my problem is A-B-C-D. C passes the request to D. C did > > not own a > > b2bua, and did not need to re-sign it. So D gets a request that > > still has > > B's signature, and A's From URI domain. Why should D believe B's > > signature, > > when it only has a relationship to C? > > > Transitive trust. D has to assume C checked B's signature and was > satisfied enough to re-initiate the SIP dialog it got from B. Yup, so then we're back to pre-Identity, because D makes that assumption right now. D has no idea if C does any verifying, or supports identity. > > I think the answer is "it shouldn't". So my problem is how will we > > get this > > mechanism off the ground, when the most applicable/beneficial use > > cases for > > it (multi-domain transit) won't work? I am unconvinced it has any > > tangible > > value other than multi-domain cases. > > > I'm unconvinced why we need to support transit in the first place, > but that's another can of very large and aggressive c.elegans. (hey, at least c.elegans are well-studied and understood ;-) If we don't support transit, why do we need an Identity-type mechanism? -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 14:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9qU-0005JY-AY; Mon, 07 Aug 2006 14:28:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9qT-0005JT-BR for sip@ietf.org; Mon, 07 Aug 2006 14:28:57 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA9qR-0007Xj-T0 for sip@ietf.org; Mon, 07 Aug 2006 14:28:57 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 5174D20A306; Mon, 7 Aug 2006 18:28:27 +0000 (UTC) Message-Id: <7.0.1.0.0.20060806123631.059eff20@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 06 Aug 2006 12:41:35 +0200 To: EKR , "Spencer Dawkins" From: Jiri Kuthan Subject: Re: [Sip] Ciphersuites in SIP In-Reply-To: <86psfgbfu2.fsf@raman.networkresonance.com> References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <86ac6kcvuf.fsf@raman.networkresonance.com> <047d01c6b7e4$8154c280$0600a8c0@china.huawei.com> <86psfgbfu2.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 18:55 04/08/2006, Eric Rescorla wrote: >"Spencer Dawkins" writes: > >>>> UAC may be configured for using any ciphers when they are dialing 911. >>> >>> You do realize that TLS implementations generally automatically >>> negotiate strong algorithms when they're available, right? So >>> in order to get a weak set of ciphers in cases where there's a >>> fairly obvious ranking (as with 40-bit algorithms) you would >>> need to configure your proxy to ONLY do the weak algorithms. >>> That's not a sane configuration. >> >> ... and, speaking of sane ... >> >> I wouldn't dare characterize the current thinking in ECRIT, the >> working group that is supposed to be worrying about emergency calling, >> but a fair amount of discussion there has bounced off the point that >> getting "I'm sorry, your 911 call isn't secure enough/at all, please >> hang up and try again while your house is burning down/you're dodging >> gunfire" isn't sane, either ... so 911 may not be quite the right >> example here, since it may not be encrypted at all. > >Well, as usual there are a number of relevant security services here. >In particular, TLS provides a separate: > >(1) Endpoint authentication and message integrity >(2) Confidentiality > >Provided you want (1), if you configure your phone correctly TLS >will securely negotiate (2) or not.... Of course, if you're willing >to have your 911 call end up talking to the wrong person, then >TLS can't help you, but that has its own threats.... I think it is a complexity trade-off. Security adds more code and complexity, which as a matter of fact decreases realibility. I think with 911 folks are more concerned by the reliability reduction caused by extra features than by reduction caused by missing security. In our 911 implementation (like in many others') we little care about features for 911 calls, be it security, database-based features, what-have-you. Simplicity is paramount. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 14:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9qc-0005Pi-1b; Mon, 07 Aug 2006 14:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9qb-0005PM-J4 for sip@ietf.org; Mon, 07 Aug 2006 14:29:05 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA9qa-0007ZU-7R for sip@ietf.org; Mon, 07 Aug 2006 14:29:05 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 8DF5A20A307; Mon, 7 Aug 2006 18:28:38 +0000 (UTC) Message-Id: <7.0.1.0.0.20060806124311.02502c68@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 06 Aug 2006 12:45:17 +0200 To: "Samir Srivastava" , "David R Oran" From: Jiri Kuthan Subject: RE: [Sip] Ciphersuites in SIP In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA91621@zrc2hxm2.corp.nor tel.com> References: <1CCA191B-0B31-4A7C-A7C2-B7C07489A859@cisco.com> <62B9B0847CC47543B6B3B5E26BD268E60DA91621@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir, I think your concerns relate generally to the transitive trust model lying under hop-by-hop security. All in all, you can't be in control of the whole path, make sure it is bug-free, super-secure, etc. If that concerns you, or your organization, I think you will be better off with e2e security protocols. -jiri At 22:51 04/08/2006, Samir Srivastava wrote: >Dave, I respectfully disagree here with you. >In the real life scenarios, even the mission critical stuff have hit the >bugs, where lot of redundancy is employed. We designed the alternate >routes, form of proxy servers etc for this... >The problem here is misconfigured/cheater proxy is making the system >totally unsecure. >Consider the following case for the cheater proxy > > >UAC ----> P1 ------> P2 -------> P3 ..... > > >Proxy P1 services to the UAC with the all known latest ciphersuites say >AES256 for the current state. But provider of Proxy P2 charges >differently to P1 for AES256. And As AES128 current mandatory >cipher-suite, it will say let us downgrade it to complete the request. >Some old may downgrade it to 3DES. If we don't have a cipher-suites >exposed to SIP, users cannot know what is done by the providers... > >Thx >Samir > > > >>You mean we forgot these in the requirements document: > >>Req 1A: Proxies MUST NOT have any bugs. >>Req 1B: Proxies MUST NOT be misconfigured by administrators > >>Ah, that makes me feel better. > > > >_______________________________________________ >Sip mailing list https://www1.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 -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 14:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9qU-0005JY-AY; Mon, 07 Aug 2006 14:28:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9qT-0005JT-BR for sip@ietf.org; Mon, 07 Aug 2006 14:28:57 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA9qR-0007Xj-T0 for sip@ietf.org; Mon, 07 Aug 2006 14:28:57 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 5174D20A306; Mon, 7 Aug 2006 18:28:27 +0000 (UTC) Message-Id: <7.0.1.0.0.20060806123631.059eff20@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 06 Aug 2006 12:41:35 +0200 To: EKR , "Spencer Dawkins" From: Jiri Kuthan Subject: Re: [Sip] Ciphersuites in SIP In-Reply-To: <86psfgbfu2.fsf@raman.networkresonance.com> References: <62B9B0847CC47543B6B3B5E26BD268E60DA18DD5@zrc2hxm2.corp.nortel.com> <86ac6kcvuf.fsf@raman.networkresonance.com> <047d01c6b7e4$8154c280$0600a8c0@china.huawei.com> <86psfgbfu2.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 18:55 04/08/2006, Eric Rescorla wrote: >"Spencer Dawkins" writes: > >>>> UAC may be configured for using any ciphers when they are dialing 911. >>> >>> You do realize that TLS implementations generally automatically >>> negotiate strong algorithms when they're available, right? So >>> in order to get a weak set of ciphers in cases where there's a >>> fairly obvious ranking (as with 40-bit algorithms) you would >>> need to configure your proxy to ONLY do the weak algorithms. >>> That's not a sane configuration. >> >> ... and, speaking of sane ... >> >> I wouldn't dare characterize the current thinking in ECRIT, the >> working group that is supposed to be worrying about emergency calling, >> but a fair amount of discussion there has bounced off the point that >> getting "I'm sorry, your 911 call isn't secure enough/at all, please >> hang up and try again while your house is burning down/you're dodging >> gunfire" isn't sane, either ... so 911 may not be quite the right >> example here, since it may not be encrypted at all. > >Well, as usual there are a number of relevant security services here. >In particular, TLS provides a separate: > >(1) Endpoint authentication and message integrity >(2) Confidentiality > >Provided you want (1), if you configure your phone correctly TLS >will securely negotiate (2) or not.... Of course, if you're willing >to have your 911 call end up talking to the wrong person, then >TLS can't help you, but that has its own threats.... I think it is a complexity trade-off. Security adds more code and complexity, which as a matter of fact decreases realibility. I think with 911 folks are more concerned by the reliability reduction caused by extra features than by reduction caused by missing security. In our 911 implementation (like in many others') we little care about features for 911 calls, be it security, database-based features, what-have-you. Simplicity is paramount. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 14:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9qc-0005Pi-1b; Mon, 07 Aug 2006 14:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9qb-0005PM-J4 for sip@ietf.org; Mon, 07 Aug 2006 14:29:05 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA9qa-0007ZU-7R for sip@ietf.org; Mon, 07 Aug 2006 14:29:05 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 8DF5A20A307; Mon, 7 Aug 2006 18:28:38 +0000 (UTC) Message-Id: <7.0.1.0.0.20060806124311.02502c68@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 06 Aug 2006 12:45:17 +0200 To: "Samir Srivastava" , "David R Oran" From: Jiri Kuthan Subject: RE: [Sip] Ciphersuites in SIP In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DA91621@zrc2hxm2.corp.nor tel.com> References: <1CCA191B-0B31-4A7C-A7C2-B7C07489A859@cisco.com> <62B9B0847CC47543B6B3B5E26BD268E60DA91621@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir, I think your concerns relate generally to the transitive trust model lying under hop-by-hop security. All in all, you can't be in control of the whole path, make sure it is bug-free, super-secure, etc. If that concerns you, or your organization, I think you will be better off with e2e security protocols. -jiri At 22:51 04/08/2006, Samir Srivastava wrote: >Dave, I respectfully disagree here with you. >In the real life scenarios, even the mission critical stuff have hit the >bugs, where lot of redundancy is employed. We designed the alternate >routes, form of proxy servers etc for this... >The problem here is misconfigured/cheater proxy is making the system >totally unsecure. >Consider the following case for the cheater proxy > > >UAC ----> P1 ------> P2 -------> P3 ..... > > >Proxy P1 services to the UAC with the all known latest ciphersuites say >AES256 for the current state. But provider of Proxy P2 charges >differently to P1 for AES256. And As AES128 current mandatory >cipher-suite, it will say let us downgrade it to complete the request. >Some old may downgrade it to 3DES. If we don't have a cipher-suites >exposed to SIP, users cannot know what is done by the providers... > >Thx >Samir > > > >>You mean we forgot these in the requirements document: > >>Req 1A: Proxies MUST NOT have any bugs. >>Req 1B: Proxies MUST NOT be misconfigured by administrators > >>Ah, that makes me feel better. > > > >_______________________________________________ >Sip mailing list https://www1.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 -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 14:30:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9ql-0005Yq-0n; Mon, 07 Aug 2006 14:29:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA9qj-0005YJ-4V for sip@ietf.org; Mon, 07 Aug 2006 14:29:13 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA9qh-0007a5-Og for sip@ietf.org; Mon, 07 Aug 2006 14:29:13 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 28C5B20A306; Mon, 7 Aug 2006 18:28:44 +0000 (UTC) Message-Id: <7.0.1.0.0.20060806124853.055cfb50@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 06 Aug 2006 12:52:45 +0200 To: "Hadriel Kaplan" , "'Samir Srivastava'" , "'David R Oran'" From: Jiri Kuthan Subject: RE: [Sip] Ciphersuites in SIP In-Reply-To: <066801c6b82d$c021af70$6601a8c0@acmepacket.com> References: <62B9B0847CC47543B6B3B5E26BD268E60DA91621@zrc2hxm2.corp.nortel.com> <066801c6b82d$c021af70$6601a8c0@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 03:23 05/08/2006, Hadriel Kaplan wrote: >Hi, >I hate to jump in on this conversation without knowing the full context, but >since you're evoking the "it's a real world problem" argument: what makes >you think as a request crosses a provider chain that the Via's from every >previous hop will make it the whole way through unscathed? Via's rarely >survive a multi-provider crossing in the real world, I believe. For this statement, I don't think there is evidence. Based on my field experience I can only witness the opposite. Which is good -- mangling and hiding header fields is quite cumbersome when it comes down to actual operating a network. >And how do you prevent some proxy simply overwriting the security-level >header in the request/response so the UAC thinks everything is ok? I wonder >what proxy could do that... > >I must be missing something very basic. Is the security-level field signed >and verified somehow by both ends? >And you also assume 2 proxies in the middle don't collude? It's not that >unlikely. I tend to conclude with the same questions though :-) If folks are concerned about implications of transitive trust model in a chain of servers (and many are, for a bunch of reasons including but not limited to political ones, robustness, etc.)), they should be looking at e2e security protocols. I agree too that mid-term, not all e2e security features are implementable. If not for other reasons, than because of NAT traversal: SDP rewriting (which is mutualy exclusive to preserving any kind of security) is still widely deployed practice under absence of wide adoption of ICE+STUN(w/TURN). I think a good mix of hbh, e2e, and nop security is needed for best security. hbh security is the only way for securing elements proxy servers must see (such as request-uri). zRTP does a great e2e job for media. For the time being SDP looks hopeless to me (i.e., a short-term nop candidate, and a long-term e2e candidate). etc. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 15:09:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAAS7-0007tn-FI; Mon, 07 Aug 2006 15:07:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAAS6-0007tg-IK for sip@ietf.org; Mon, 07 Aug 2006 15:07:50 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAAS5-0002o3-96 for sip@ietf.org; Mon, 07 Aug 2006 15:07:50 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k77J7jI27258; Mon, 7 Aug 2006 15:07:46 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Mon, 7 Aug 2006 14:07:46 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB336B5@zrc2hxm2.corp.nortel.com> In-Reply-To: <44FE3792.3020105@lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca5A9Wm/JzKjD+QR0WKA+tTJvuiLgBUKsew From: "Samir Srivastava" To: "Vijay K. Gurbani" , "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Vijay, As per our off-list discussion on the SIPSEC URI before the meeting, you had one method CONNECT which traverses across the SIP proxies, what information is passed in that. This information is of concern. Thx Samir=20 > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com]=20 > Sent: Tuesday, September 05, 2006 7:51 PM > To: EKR > Cc: sip@ietf.org > Subject: Re: [Sip] Ciphersuites in SIP >=20 > Eric Rescorla wrote: > > Huh? >=20 > Sorry; we had discussed this in the SIP security ad-hoc in=20 > Montreal. Establishing a security tunnel across proxies to=20 > exchange certs end-to-end: > http://www.ietf.org/internet-drafts/draft-gurbani-sip-sipsec-00.txt >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Bell Laboratories, Lucent Technologies, Inc. > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >=20 > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 15:10:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAATJ-0000EC-6l; Mon, 07 Aug 2006 15:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAATI-0000AB-1c for sip@ietf.org; Mon, 07 Aug 2006 15:09:04 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAATF-0002tm-OD for sip@ietf.org; Mon, 07 Aug 2006 15:09:04 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Aug 2006 12:09:01 -0700 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.20060308/8.12.11) with ESMTP id k77J91ZG006170; Mon, 7 Aug 2006 12:09:01 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k77J91VP029966; Mon, 7 Aug 2006 12:09:01 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-6.cisco.com [10.21.152.6]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k77J1QHC007720; Mon, 7 Aug 2006 12:01:27 -0700 Message-ID: <44D78FCF.3020207@cisco.com> Date: Mon, 07 Aug 2006 12:09:03 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA917E3@zrc2hxm2.corp.nortel.com> <86ejvw5bz3.fsf@raman.networkresonance.com> <44FE358A.4080401@lucent.com> <86wt9m37hg.fsf@raman.networkresonance.com> <44FE3792.3020105@lucent.com> In-Reply-To: <44FE3792.3020105@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=375; t=1154977741; x=1155841741; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20Ciphersuites=20in=20SIP; X=v=3Dcisco.com=3B=20h=3DV4DCubIzQx+YkIhK61L4bpDIPK4=3D; b=ZXC3iL4KrOKuOSv5HEy6RKGrARqA2pL6e9gxjv/0Kgx8uq4PzBZ4o/bxzZAjOkPt4DWTR/6I piahEC2RL45vfonQp2kDxPlABCjw5J1Zb4mqInxCypDus1B1f5bwCYvj; X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > Eric Rescorla wrote: > >> Huh? > > > Sorry; we had discussed this in the SIP security ad-hoc in > Montreal. Establishing a security tunnel across proxies to > exchange certs end-to-end: > http://www.ietf.org/internet-drafts/draft-gurbani-sip-sipsec-00.txt Speaking of which, have I missed the notes from that meeting? Mike _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 15:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAAxQ-0007eI-FV; Mon, 07 Aug 2006 15:40:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAAxO-0007eD-DV for sip@ietf.org; Mon, 07 Aug 2006 15:40:10 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAAxN-0007Bx-59 for sip@ietf.org; Mon, 07 Aug 2006 15:40:10 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A72102EC; Mon, 07 Aug 2006 15:40:17 -0400 From: "Hadriel Kaplan" To: "'Jiri Kuthan'" Subject: RE: [Sip] Ciphersuites in SIP Date: Mon, 7 Aug 2006 15:40:04 -0400 Message-ID: <07c501c6ba59$48542e90$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca6T2gzulQ619iET4mxBQUGpahAdAABsoLQ In-Reply-To: <7.0.1.0.0.20060806124853.055cfb50@iptel.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org] > Sent: Sunday, August 06, 2006 6:53 AM > > At 03:23 05/08/2006, Hadriel Kaplan wrote: > >Hi, > >I hate to jump in on this conversation without knowing the full context, > but > >since you're evoking the "it's a real world problem" argument: what makes > >you think as a request crosses a provider chain that the Via's from every > >previous hop will make it the whole way through unscathed? Via's rarely > >survive a multi-provider crossing in the real world, I believe. > > For this statement, I don't think there is evidence. Based on my field > experience I can only witness the opposite. Which is good -- mangling > and hiding header fields is quite cumbersome when it comes down to > actual operating a network. Well, this is off-topic, but I would guess that's because of the differing customer bases we serve. :) Typically you won't know it's happened. All it takes for a multi-provider multi-hop chain is for one of them to do it, and it's done. Whereas assuming the Via's are all included and left alone requires all the hops to do so. And devices other than SBCs do it too, but it's much more fashionable to blame SBCs. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 16:14:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GABTQ-0005MS-A4; Mon, 07 Aug 2006 16:13:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GABTO-0005M3-T7 for sip@ietf.org; Mon, 07 Aug 2006 16:13:14 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GABTN-0004by-Hx for sip@ietf.org; Mon, 07 Aug 2006 16:13:14 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k77KDAI21277; Mon, 7 Aug 2006 16:13:10 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Mon, 7 Aug 2006 15:13:05 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB337F3@zrc2hxm2.corp.nortel.com> In-Reply-To: <066c01c6b831$119edcd0$6601a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca4Ee1mSqtzT+FMTCmw5jp5Vdr7fQAADN0gAAD83XAAAKbp8AAFYo3AAIpQiAA= From: "Samir Srivastava" To: "Hadriel Kaplan" , "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hadriel, Thx for your comments. See in -line below. Thx Samir > =20 > Spammers don't care about you. If your number is not listed=20 > on any database (fat chance of that, BTW), they won't call=20 > you. That doesn't stop them from spamming. Their goal is=20 > broad coverage, not a specific individual. If no one's=20 > number was in a database, then few people would be able to=20 > communicate. And spamming would still be possible, since=20 > they can simply war-dial/number-scan - the issue is how to=20 > detect+stop them, not hope you keep lists of fixed-length=20 > numbers from them. IMO, preventing Spam is an orthogonal=20 > issue to ensuring end-end eavesdropping protection,=20 > authentication, etc. Writing email addresses in obfuscated form is temporarily measure for avoiding spammers to learn the attended / valid email addresses from scanning on the web etc. Email addresses also within a domain can be found. Valid domain are known too everybody. And they can war emailed too. Spammers can do war-dialing too. But here they can know the attended no / URI rightaway. Less secure hops open up the details which can be used for various purposes, URI/no learning is one of it. If my SBC can find out that a source is war dialing / scanning URI, then it can right away stop those war dialing/ URI scanning requests. I would expect this from the good edge protection device (SBC/Edge Firewalls etc). This is very similar to port scanning, which is avoided by the firewalls. =20 =20 > You're assuming Biloxi will do this, because you're assuming=20 > it has an incentive to reject the request. It's quite the=20 > opposite. Biloxi has a relationship with Alberta. Biloxi=20 > makes money from Alberta. If Alberta doesn't want to use a=20 > ciphersuite of some UAC's choosing, Biloxi's going to agree=20 > with Alberta, not the UAC. =20 >=20 Let me first draw the diagram Alice --- Atlanta --- Alberta --- Biloxi -- Bob I don't agree with you here at all. Biloxi does support the cipher-suite asked by Alice, these cipher-suites are ordered with qValued also. Biloxi charges here more for AES256 (more resources etc) and it is supported between Alberta and Biloxi. AES256 is the most preferred cipher-suite by the UAC also as indicated in the header. If Alberta uses the 40 bit or 3DES etc stuff, then biloxi is loosing the money. So why Biloxi will co-operate with Alberta here ? Am I missing something here. > -hadriel >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 16:28:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GABgQ-0000NC-BZ; Mon, 07 Aug 2006 16:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GABgP-0000N6-6b for sip@ietf.org; Mon, 07 Aug 2006 16:26:41 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GABgN-0000wf-Qu for sip@ietf.org; Mon, 07 Aug 2006 16:26:41 -0400 Received: from [192.168.2.104] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k77KSmkI015424 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 7 Aug 2006 15:28:49 -0500 In-Reply-To: <44D78FCF.3020207@cisco.com> References: <62B9B0847CC47543B6B3B5E26BD268E60DA917E3@zrc2hxm2.corp.nortel.com> <86ejvw5bz3.fsf@raman.networkresonance.com> <44FE358A.4080401@lucent.com> <86wt9m37hg.fsf@raman.networkresonance.com> <44FE3792.3020105@lucent.com> <44D78FCF.3020207@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Ciphersuites in SIP Date: Mon, 7 Aug 2006 15:26:39 -0500 To: Michael Thomas X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 7, 2006, at 2:09 PM, Michael Thomas wrote: > Vijay K. Gurbani wrote: > >> Eric Rescorla wrote: >> >>> Huh? >> >> >> Sorry; we had discussed this in the SIP security ad-hoc in >> Montreal. Establishing a security tunnel across proxies to >> exchange certs end-to-end: >> http://www.ietf.org/internet-drafts/draft-gurbani-sip-sipsec-00.txt > > Speaking of which, have I missed the notes from that meeting? > > Mike http://www.softarmor.com/sipwg/meets/ietf66/notes/minutes-sip- ietf66.html -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 17:17:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACRx-00057y-Mw; Mon, 07 Aug 2006 17:15:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACRw-00057t-E8 for sip@ietf.org; Mon, 07 Aug 2006 17:15:48 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GACRu-0006oV-5V for sip@ietf.org; Mon, 07 Aug 2006 17:15:48 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k77LFfrb025089; Mon, 7 Aug 2006 16:15:41 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k77LFYm13848; Mon, 7 Aug 2006 16:15:39 -0500 (CDT) Message-ID: <44D7AD76.4030102@lucent.com> Date: Mon, 07 Aug 2006 16:15:34 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samir Srivastava Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DB336B5@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DB336B5@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava wrote: > Hi Vijay, > > As per our off-list discussion on the SIPSEC URI before the meeting, > you had one method CONNECT which traverses across the SIP proxies, what > information is passed in that. As much as, or as little as you want. Since this is still a work in progress, nothing is nailed down at this point in time. I expect that future revisions of the draft will be more specific. Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 17:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACdm-0001rj-BW; Mon, 07 Aug 2006 17:28:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACdk-0001qt-Je for sip@ietf.org; Mon, 07 Aug 2006 17:28:00 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GACdj-0002Pj-8S for sip@ietf.org; Mon, 07 Aug 2006 17:28:00 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 07 Aug 2006 14:27:59 -0700 X-IronPort-AV: i="4.07,220,1151910000"; d="scan'208"; a="1844962641:sNHT26215220" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k77LRwjG012653; Mon, 7 Aug 2006 14:27:58 -0700 Received: from [192.168.1.2] (sjc-vpn4-421.cisco.com [10.21.81.165]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k77LRtuE004308; Mon, 7 Aug 2006 14:27:58 -0700 (PDT) In-Reply-To: <5D1A7985295922448D5550C94DE291801E50FD@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE291801E50FD@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Continuation of WGLC on draft-ietf-sip-gruu-10 Date: Mon, 7 Aug 2006 14:27:49 -0700 To: "Drage, Keith ((Keith))" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2763; t=1154986078; x=1155850078; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Continuation=20of=20WGLC=20on=20draft-ietf-sip-gruu-10; X=v=3Dcisco.com=3B=20h=3DNNrhULi6eItkDsaAofFi3o1DtlE=3D; b=TuOrhMOCBOFYbUmubtDfbRgml0aQioySuLRVsd2UDk5a4qqzfNi4594le/feAqfvI3jQaWSb iS/bW4lRYTpFbVH+GhlBwdoCfc+QQHuPn14ShZ1hVt7p85m5y4sRT3TL; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just as a note - Sep 4 is a holiday many places. On Aug 5, 2006, at 1:31 PM, Drage, Keith ((Keith)) wrote: > Working Group Last Call > ----------------------- > > Jonathan has just published > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-10.txt which > should take into account all the major comments that have been so far > received on this document. > > Having initiated WGLC on this document on 13th January 2004, and > revised > that WGLC on 5th July 2004 and 26th October 2005 we would really > like to > reach a final conclusion of this WGLC. > > Therefore please review the document and submit your WGLC comments > within two weeks, ie. By the 21st August 2006. > > Process > ------- > > In addition to an open invitation for review by all members of the > working group, we will be soliciting full review by a number of > experts > who we believe will provide a good and complete understanding of the > issues and problems, if any, with the document. If you consider you > should be part of this list this please contact the WG chairs. > > The WG chairs will compile all submitted comments into a single review > document which will be discussed on the conference call below. Please > therefore submit your comments (to the SIP WG list and the WG chairs) > with information under the following headings for each comment: > > - location in document > - nature of comment (editorial, minor technical, critical error, > absolute show stopper - use your judgement on this) > - comment > - proposed fix > > We intend to have a conference call for reviewers to conclude on the > quality of the document on Monday 4th September at: > > 8:00 am Pacific Time > 10:00 am Central US Time > 11:00 am Eastern US Time > 4:00 pm UK > 5:00 pm Central European Summer Time > > Bridge details as follows: > > Access Phone Number: 8007718734 > International Access Phone Number: +1 6477233953 > 7-Digit Access Code: 5776249 > > While this call is open to all WG members, we would expect only people > who have reviewed the document on this conference call. For details of > the process please see previous communication. Note that the above > does > include those reviewers who reviewed the document and had no > comments - > if you are in this class, please report it. > > Regards > > Keith > > Keith Drage > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 07 18:58:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAE20-0003d8-7w; Mon, 07 Aug 2006 18:57:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAE1y-0003d0-KK for sip@ietf.org; Mon, 07 Aug 2006 18:57:06 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAE1x-0000bW-Aw for sip@ietf.org; Mon, 07 Aug 2006 18:57:06 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A54B03C8; Mon, 07 Aug 2006 18:57:15 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" Subject: RE: [Sip] Ciphersuites in SIP Date: Mon, 7 Aug 2006 18:57:04 -0400 Message-ID: <08a301c6ba74$cd406540$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca4Ee1mSqtzT+FMTCmw5jp5Vdr7fQAADN0gAAD83XAAAKbp8AAFYo3AAIpQiAAABQvfMA== In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DB337F3@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Samir, comments inline... > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > > Writing email addresses in obfuscated form is temporarily measure for > avoiding spammers to learn the attended / valid email addresses from > scanning on the web etc. Email addresses also within a domain can be > found. Valid domain are known too everybody. And they can war emailed > too. Spammers can do war-dialing too. But here they can know the > attended no / URI rightaway. Less secure hops open up the details which > can be used for various purposes, URI/no learning is one of it. I think I already mentioned why e164's just don't benefit from it as email addresses do. But even for email, do you think the spammers get their addresses by sniffing SMTP links? (I'm honestly curious - do they do that?) I would think they'd just harvest them from lists-dealers and mailing-list archives and such. > If my > SBC can find out that a source is war dialing / scanning URI, then it > can right away stop those war dialing/ URI scanning requests. I would > expect this from the good edge protection device (SBC/Edge Firewalls > etc). This is very similar to port scanning, which is avoided by the > firewalls. I assume most SBCs can already do that. (it's not a new idea) At least from consumer phones they can. But stopping this from peers is incredibly difficult in the real world, with the exception of trivial spit scenarios; and if you consider false-positives unacceptable (which I do). Whether numbers are public sniffed or not doesn't really help - it's really orthogonal, IMHO. > Let me first draw the diagram > > Alice --- Atlanta --- Alberta --- Biloxi -- Bob > > I don't agree with you here at all. Biloxi does support the cipher-suite > asked by Alice, these cipher-suites are ordered with qValued also. > Biloxi charges here more for AES256 (more resources etc) and it is > supported between Alberta and Biloxi. AES256 is the most preferred > cipher-suite by the UAC also as indicated in the header. If Alberta uses > the 40 bit or 3DES etc stuff, then biloxi is loosing the money. So why > Biloxi will co-operate with Alberta here ? Am I missing something here. Well, it would certainly be a new idea: let UACs else-where make Alberta pay Biloxi more money by the ciphersuite they ask for. In fact I sense a money-making scheme here somewhere, like where Biloxi hires people to use UACs expressly to do this all day long. :) Unless you mean Alberta would then charge more for it, and pass the costs back to Alice, which would certainly discourage Alice from using strong ciphersuites. Not so good. I really don't think we'd want to have a relationship between ciphersuites to charging models, because it would be a dis-incentive; nor is there such a model today AFAIK. Biloxi cooperates with Alberta because Alberta is Biloxi's customer, not Alice. The idea that Alice can co-opt Biloxi against Alberta is very strange to me, and not one Alberta is going to allow anyway. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 19:18:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAEKr-0007d4-0t; Mon, 07 Aug 2006 19:16:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAEKp-0007cz-Ax for sip@ietf.org; Mon, 07 Aug 2006 19:16:35 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAEKo-0003lM-1J for sip@ietf.org; Mon, 07 Aug 2006 19:16:35 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k77NGT025938; Mon, 7 Aug 2006 19:16:30 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Mon, 7 Aug 2006 18:16:26 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB33AD9@zrc2hxm2.corp.nortel.com> In-Reply-To: <066d01c6b836$2891daf0$6601a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca4G/BVKCIgrhr5QWqpMJBLwKXZsAACBiBgAAOh9GAAkOqMIA== From: "Samir Srivastava" To: "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hadriel, Response in line below. Thx Samir > Not to belabor the point of spamming, because I really don't=20 > think that's the benefit of assured hop-by-hop encrypt, but=20 > email spamming needs lists because the target name@domain is=20 > so variable. (yes, I know they probe too) >=20 > Spamming e164's is far easier without a list, because the=20 > target is a very finite set: fixed-length integers of=20 > specific pattern ranges. What's worse, they're generally=20 > allocated in blocks, so the range is not very big and the=20 > domain can be inferred. If we can get broad use of real=20 > alphanum sip uri's, then we're back to lists becoming more useful. > Anyway... back on topic. In another thread. I responded on this. >=20 >=20 > > > The proxy in the middle just changes the headers. > >=20 > > This header should be part of hash computations like used=20 > in Identity. > > So any middle-man tampering can be caught. Though it=20 > assumes that UAS=20 > > is most trustworthy. Providers providing the services=20 > (making money)=20 > > have more reasons to become cheater. End users don't have=20 > this motivation. >=20 > But you just pointed out the flaw. Providers have an=20 > incentive to "cheat": > they want the call to succeed so they get paid.=20 >=20 > So imagine 2 providers in the middle. They decide to connect=20 > over an L2 VPN through a carrier, which they've been told is=20 > "secure". A request comes through that says "use TLS". Do=20 > you think they're going to reject it? No. > Then they find out some Via gave them away. So do you think=20 > they're going to set their proxies to remove/modify their=20 > Via's, or start using TLS instead? My guess is the former. =20 >=20 =20 Extending this mechanism to IPSEC is an OPEN ISSUE as per the draft. I am not an IPSEC expert. I don't know how difficult is to get cipher-suite info from kernel space to user space etc.. On a side note, I view VPN tunnels as a temporarily measure. It is not optimized for multimedia stuff. IMHO, eventually provider will move to TLS and SRTP. There have been some discussions on this in VOIPSEC list sometime back. > Obviously some providers will do the right thing. But those=20 > are the ones that will probably use TLS or IPSec anyway and=20 > you don't need this mechanism to defend against. =20 Level of security is important stuff. 40 bit stuff is not equal to AES256. And we have AES 128 as mandatory cipher-suite as per 3261. So how can I get AES256 at each hop, without specifying explicitly. When I started looking into this, I was looking into the future proofness of this stuff. Then I figured out this use also. I will open another thread later for FUTURE proofness. It didn't get any discussions. >=20 > -hadriel >=20 >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 07 22:04:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAGv1-0001uv-AZ; Mon, 07 Aug 2006 22:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAGuz-0001uq-W5 for sip@ietf.org; Mon, 07 Aug 2006 22:02:05 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAGux-0001aY-Kq for sip@ietf.org; Mon, 07 Aug 2006 22:02:05 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id A0A001DC; Mon, 07 Aug 2006 22:02:08 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" Subject: RE: [Sip] Ciphersuites in SIP Date: Mon, 7 Aug 2006 22:01:57 -0400 Message-ID: <08d401c6ba8e$a1f2bcc0$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca4G/BVKCIgrhr5QWqpMJBLwKXZsAACBiBgAAOh9GAAkOqMIAAE0ogA In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DB33AD9@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Samir, more comments... > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > > Extending this mechanism to IPSEC is an OPEN ISSUE as per the draft. I > am not an IPSEC expert. I don't know how difficult is to get > cipher-suite info from kernel space to user space etc.. > On a side note, I view VPN tunnels as a temporarily measure. It is not > optimized for multimedia stuff. IMHO, eventually provider will move to > TLS and SRTP. There have been some discussions on this in VOIPSEC list > sometime back. IPSEC is not only about VPN tunnels. It has transport mode as well. (and likewise, there are such things as SSL VPNs) Even in tunnel mode ipsec may be as secure as TLS, and only applied to signaling (and just as "optimized for multimedia stuff"). I was actually using the L2-VPN as an example because it's considered secure by some folks, yet others consider it not at all, and some of that depends on the implementation details. Even TLS somewhat depends on the implementation details (e.g., there are TLS-off-loaders, which some people think is secure while others not). The point, though, is that there are numerous implementation details no UAC would be able to articulate, and it's a hop-by-hop decision what "secure" means - and that's the big rub. If you add IPSec as another option, and some UAC encodes only TLS while another only IPSec, then a provider has to have both IPSec and TLS?? Will you specify key exchange and re-keying policies as well? And RNG algorithms? And who the CA can be? And where they store the private keys? And how they secure the box? Etc., etc. Focusing on key-length seems odd to me. > > Obviously some providers will do the right thing. But those > > are the ones that will probably use TLS or IPSec anyway and > > you don't need this mechanism to defend against. > > Level of security is important stuff. 40 bit stuff is not equal to > AES256. And we have AES 128 as mandatory cipher-suite as per 3261. So > how can I get AES256 at each hop, without specifying explicitly. You can't, and you won't, IMO. If they're doing 40-bit vs. 128 there is probably some legitimate reason (I hope). I guess it would be novel to use SIP as a "did you know there's 256-bit now?" notification check, for the providers that decided to support the proxy-require mechanism, but I can't imagine this would do anything but cause headaches for UACs and proxies and providers and people would just turn it off. I just think it raises another bar to implementing hop-by-hop encrypt+auth, for which we're struggling to get people past the first bar. My 2 cents anyway. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 01:29:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAK7o-0008Q1-1y; Tue, 08 Aug 2006 01:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAK7m-0008Pl-Os for sip@ietf.org; Tue, 08 Aug 2006 01:27:30 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAK7k-0008F5-Fz for sip@ietf.org; Tue, 08 Aug 2006 01:27:30 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k785ROF22590; Tue, 8 Aug 2006 01:27:24 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 8 Aug 2006 00:27:23 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB33BE2@zrc2hxm2.corp.nortel.com> In-Reply-To: <7.0.1.0.0.20060806124311.02502c68@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca6T2BL6+j2Jj3dQfG/N0/wVGAlRQAWcHjQ From: "Samir Srivastava" To: "Jiri Kuthan" , "David R Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jiri, My only requirement is, I should get the PSTN kind of security in VoIP. In PSTN, I don't have to worry about the call pattern tracking etc by anybody tapping on the wire. This can be done only under CALEA by the duly authorized personnel when subpoena etc opened by the legal authorities. I can talk my SSN, bank a/c etc without any fear. If SIP cannot provide this, then It will be bound to exist _only_ in the *islands*. Which I (hope group also) don't like. Given Hop by Hop nature of SIP, the proposal intended to address the issue within the SIP framework.=20 Thx Samir =20 > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org]=20 > Sent: Sunday, August 06, 2006 3:45 AM > To: Srivastava, Samir (SC100:8826); David R Oran > Cc: sip@ietf.org > Subject: RE: [Sip] Ciphersuites in SIP >=20 > Samir, >=20 > I think your concerns relate generally to the transitive=20 > trust model lying under hop-by-hop security. All in all, you=20 > can't be in control of the whole path, make sure it is=20 > bug-free, super-secure, etc. If that concerns you, or your=20 > organization, I think you will be better off with e2e=20 > security protocols. >=20 > -jiri >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 01:32:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAKB3-0002Du-Rl; Tue, 08 Aug 2006 01:30:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAKB2-0002Dm-1r for sip@ietf.org; Tue, 08 Aug 2006 01:30:52 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAKAz-0000QL-OC for sip@ietf.org; Tue, 08 Aug 2006 01:30:52 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k785Oqs02021; Tue, 8 Aug 2006 01:24:52 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 8 Aug 2006 00:30:45 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB33BE4@zrc2hxm2.corp.nortel.com> In-Reply-To: <7.0.1.0.0.20060806123631.059eff20@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca6T2zlR2uNJLUhRCejreJcE8mjEAAXAEYw From: "Samir Srivastava" To: "Jiri Kuthan" , "EKR" , "Spencer Dawkins" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jiri, in line below. Thx Samir >=20 > In our 911 implementation (like in many others') we little=20 > care about features for 911 calls, be it security,=20 > database-based features, what-have-you. > Simplicity is paramount. >=20 I quoted the 911 as one extreme where quickest call set up is paramount. The other example of bank a/c was where security is paramount. Simplicity is needed provided it feels me secure also... > -jiri >=20 >=20 > -- > Jiri Kuthan http://iptel.org/~jiri/=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 02:30:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAL4v-0004jZ-VZ; Tue, 08 Aug 2006 02:28:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAL4t-0004d4-Hc for sip@ietf.org; Tue, 08 Aug 2006 02:28:35 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAL4s-0001mB-6X for sip@ietf.org; Tue, 08 Aug 2006 02:28:35 -0400 Received: from [71.240.232.162] (helo=JMHLap3.stevecrocker.com) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GAL3V-0002ul-RE; Tue, 08 Aug 2006 02:27:10 -0400 Message-Id: <7.0.1.0.0.20060808022151.03fa6650@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 08 Aug 2006 02:27:00 -0400 To: "Samir Srivastava" ,"Jiri Kuthan" , "David R Oran" From: "Joel M. Halpern" Subject: RE: [Sip] Ciphersuites in SIP In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DB33BE2@zrc2hxm2.corp.nor tel.com> References: <7.0.1.0.0.20060806124311.02502c68@iptel.org> <62B9B0847CC47543B6B3B5E26BD268E60DB33BE2@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120e26356c0b04704708d772654109fcee0651292a7c140c43c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.240.232.162 X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A couple of points about this: a) We have lots of experience indicating that folks will use (and use widely) protocols that are less secure than we would like. The assertion that It must be secure or "it will exist only in *islands*" does not match the observable history. b) The PSTN is no where near as secure as the description below pretends. There were and are many known security issues with SS7, and many ways that hackers could and did get at information in those systems. c) By providing for end-to-end security over and above hop-by-hop security, the current definitions already allow for servers and users to offer and utilize significantly more secure capabilities than have existed heretofore. d) Adding extra mechanisms to the protocol to try to detect very specific cases, with known limitations to those mechanisms, is not an effective approach to the sorts of problems you have indicated you would like to see addressed. e) Much of your argument, if I have read and understood it properly, is about what proxies might choose to do if they choose to do a bad job offering security capabilities. While such a choice is a problem, it is not a protocol definition problem. Yours, Joel M. Halpern At 01:27 AM 8/8/2006, Samir Srivastava wrote: >Hi Jiri, > > My only requirement is, I should get the PSTN kind of security in >VoIP. In PSTN, I don't have to worry about the call pattern tracking etc >by anybody tapping on the wire. This can be done only under >CALEA by the duly authorized personnel when subpoena etc opened by the >legal authorities. I can talk my SSN, bank a/c etc without any fear. > > If SIP cannot provide this, then It will be bound to exist _only_ in >the *islands*. Which I (hope group also) don't like. Given Hop by Hop >nature of SIP, the proposal intended to address the issue within the >SIP framework. > >Thx >Samir > > > > -----Original Message----- > > From: Jiri Kuthan [mailto:jiri@iptel.org] > > Sent: Sunday, August 06, 2006 3:45 AM > > To: Srivastava, Samir (SC100:8826); David R Oran > > Cc: sip@ietf.org > > Subject: RE: [Sip] Ciphersuites in SIP > > > > Samir, > > > > I think your concerns relate generally to the transitive > > trust model lying under hop-by-hop security. All in all, you > > can't be in control of the whole path, make sure it is > > bug-free, super-secure, etc. If that concerns you, or your > > organization, I think you will be better off with e2e > > security protocols. > > > > -jiri > > > >_______________________________________________ >Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 08 03:39:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAMA0-0005k0-6O; Tue, 08 Aug 2006 03:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAM9z-0005jv-1B for sip@ietf.org; Tue, 08 Aug 2006 03:37:55 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAM9x-0004yO-Mg for sip@ietf.org; Tue, 08 Aug 2006 03:37:54 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k787bnY25390; Tue, 8 Aug 2006 03:37:49 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 8 Aug 2006 02:37:48 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB33C09@zrc2hxm2.corp.nortel.com> In-Reply-To: <7.0.1.0.0.20060806124853.055cfb50@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca6T2bT3bj/7vmMQS6ArDY+yMGbJQAbHMBA From: "Samir Srivastava" To: "Jiri Kuthan" , "Hadriel Kaplan" , "David R Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jiri, in-line below. Thx Samir >=20 > For this statement, I don't think there is evidence. Based on=20 > my field experience I can only witness the opposite. Which is=20 > good -- mangling and hiding header fields is quite cumbersome=20 > when it comes down to actual operating a network. >=20 If there is SBC/B2BUA in between, then it need to make sure that Ciphers etc specified are acknowledged in other part of the network where it is client. The normal proxy stuff works well. I will add B2BUA stuff too in the next version. >=20 > I tend to conclude with the same questions though :-) If=20 > folks are concerned about implications of transitive trust=20 > model in a chain of servers (and many are, for a bunch of=20 > reasons including but not limited to political ones,=20 > robustness, etc.)), they should be looking at e2e security protocols.=20 >=20 > I agree too that mid-term, not all e2e security features are=20 > implementable. > If not for other reasons, than because of NAT traversal: SDP=20 > rewriting (which is mutualy exclusive to preserving any kind=20 > of security) is still widely deployed practice under absence=20 > of wide adoption of ICE+STUN(w/TURN). >=20 > I think a good mix of hbh, e2e, and nop security is needed=20 > for best security. > hbh security is the only way for securing elements proxy=20 > servers must see (such as request-uri). zRTP does a great e2e=20 > job for media. For the time being SDP looks hopeless to me=20 > (i.e., a short-term nop candidate, and a long-term e2e=20 > candidate). etc. I don't know how far FCC will let zRTP go in view of CALEA compliance it enforces on providers. Even email/IM records are necessary by the law enforcement. It is big political issue.. Also I don't foresee FAX going to end of life like Telex in near future. SDP in e2e doesn't avoid the call pattern tracking etc given to attackers by less secure hops. Refer my other responses to Joel's email. >=20 > -jiri >=20 >=20 > -- > Jiri Kuthan http://iptel.org/~jiri/ =20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 03:56:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAMQX-0005Y3-Ts; Tue, 08 Aug 2006 03:55:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAMQW-0005Xw-93 for sip@ietf.org; Tue, 08 Aug 2006 03:55:00 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAMQT-0006xS-Uc for sip@ietf.org; Tue, 08 Aug 2006 03:55:00 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k787ssF05118; Tue, 8 Aug 2006 03:54:54 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 8 Aug 2006 02:54:53 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB33C0F@zrc2hxm2.corp.nortel.com> In-Reply-To: <08d401c6ba8e$a1f2bcc0$6601a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca4G/BVKCIgrhr5QWqpMJBLwKXZsAACBiBgAAOh9GAAkOqMIAAE0ogAAA1qkAA= From: "Samir Srivastava" To: "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hadriel, Thx for your comments. I will consider IPSEC issue, when group arrives on the consensus (Even rough in IETF terms) for cipher-suite, Secure Transport Protocol Name (TLS, DTLS, any other future...), versions etc exposed to SIP. =20 Then I will see how TLS to IPSEC and vice versa and applicability to IPSEC .. Thx Samir > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, August 07, 2006 7:02 PM > To: Srivastava, Samir (SC100:8826) > Cc: sip@ietf.org > Subject: RE: [Sip] Ciphersuites in SIP >=20 > Hi Samir, more comments... >=20 > > -----Original Message----- > > From: Samir Srivastava [mailto:samirsr@nortel.com] > > > > Extending this mechanism to IPSEC is an OPEN ISSUE as per=20 > the draft.=20 > > I am not an IPSEC expert. I don't know how difficult is to get=20 > > cipher-suite info from kernel space to user space etc.. > > On a side note, I view VPN tunnels as a temporarily=20 > measure. It is not=20 > > optimized for multimedia stuff. IMHO, eventually provider=20 > will move to=20 > > TLS and SRTP. There have been some discussions on this in=20 > VOIPSEC list=20 > > sometime back. >=20 > IPSEC is not only about VPN tunnels. It has transport mode=20 > as well. (and likewise, there are such things as SSL VPNs) =20 > Even in tunnel mode ipsec may be as secure as TLS, and only=20 > applied to signaling (and just as "optimized for multimedia stuff").=20 >=20 > I was actually using the L2-VPN as an example because it's=20 > considered secure by some folks, yet others consider it not=20 > at all, and some of that depends on the implementation=20 > details. Even TLS somewhat depends on the implementation=20 > details (e.g., there are TLS-off-loaders, which some people=20 > think is secure while others not). The point, though, is=20 > that there are numerous implementation details no UAC would=20 > be able to articulate, and it's a hop-by-hop decision what=20 > "secure" means - and that's the big rub. =20 >=20 > If you add IPSec as another option, and some UAC encodes only=20 > TLS while another only IPSec, then a provider has to have=20 > both IPSec and TLS??=20 > Will you specify key exchange and re-keying policies as well?=20 > And RNG algorithms? And who the CA can be? And where they=20 > store the private keys? And how they secure the box? Etc., etc. =20 > Focusing on key-length seems odd to me. >=20 >=20 > > > Obviously some providers will do the right thing. But=20 > those are the=20 > > > ones that will probably use TLS or IPSec anyway and you=20 > don't need=20 > > > this mechanism to defend against. > >=20 > > Level of security is important stuff. 40 bit stuff is not=20 > equal to=20 > > AES256. And we have AES 128 as mandatory cipher-suite as=20 > per 3261. So=20 > > how can I get AES256 at each hop, without specifying explicitly. >=20 > You can't, and you won't, IMO. If they're doing 40-bit vs.=20 > 128 there is probably some legitimate reason (I hope). I=20 > guess it would be novel to use SIP as a "did you know there's=20 > 256-bit now?" notification check, for the providers that=20 > decided to support the proxy-require mechanism, but I can't=20 > imagine this would do anything but cause headaches for UACs=20 > and proxies and providers and people would just turn it off. =20 > I just think it raises another bar to implementing hop-by-hop=20 > encrypt+auth, for which we're struggling to get people past=20 > the first bar. My 2 cents anyway. >=20 > -hadriel >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 04:04:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAMYD-0001jF-1g; Tue, 08 Aug 2006 04:02:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAMYA-0001j9-Vz for sip@ietf.org; Tue, 08 Aug 2006 04:02:54 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAMY9-0008LY-NH for sip@ietf.org; Tue, 08 Aug 2006 04:02:54 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7882pY01280; Tue, 8 Aug 2006 04:02:51 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 8 Aug 2006 03:02:50 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB33C11@zrc2hxm2.corp.nortel.com> In-Reply-To: <08d401c6ba8e$a1f2bcc0$6601a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca4G/BVKCIgrhr5QWqpMJBLwKXZsAACBiBgAAOh9GAAkOqMIAAE0ogAAA2gcMA= From: "Samir Srivastava" To: "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hadriel, Sorry, I missed the second comment in the last response=20 Thx Samir >=20 > You can't, and you won't, IMO. If they're doing 40-bit vs.=20 > 128 there is probably some legitimate reason (I hope). I=20 > guess it would be novel to use SIP as a "did you know there's=20 > 256-bit now?" notification check, for the providers that=20 > decided to support the proxy-require mechanism, but I can't=20 > imagine this would do anything but cause headaches for UACs=20 > and proxies and providers and people would just turn it off. =20 > I just think it raises another bar to implementing hop-by-hop=20 > encrypt+auth, for which we're struggling to get people past=20 > the first bar. My 2 cents anyway. Let me draw some parallel, I feel more comfortable when my virus scanner tells me it is up-to-date and there is no virus on my PC. The same will apply to dynamic nature of security-level in TLS with different versions/cipher-suites etc. It will be always N+1 game.=20 >=20 > -hadriel >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 05:23:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GANmn-00009a-9s; Tue, 08 Aug 2006 05:22:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GANml-00006w-Ff for sip@ietf.org; Tue, 08 Aug 2006 05:22:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAM7d-0004HF-AJ for sip@ietf.org; Tue, 08 Aug 2006 03:35:29 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GALxQ-0006tx-QC for sip@ietf.org; Tue, 08 Aug 2006 03:24:57 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k787Iss11575; Tue, 8 Aug 2006 03:18:54 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 8 Aug 2006 02:24:44 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB33C06@zrc2hxm2.corp.nortel.com> In-Reply-To: <7.0.1.0.0.20060808022151.03fa6650@stevecrocker.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca6s+l3++YJqGJgSkqX9arA5diHugAA1hGg From: "Samir Srivastava" To: "Joel M. Halpern" , "Jiri Kuthan" , "David R Oran" X-Spam-Score: -2.3 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Joel, Response in-line below.=20 Thx Samir >=20 > A couple of points about this: > a) We have lots of experience indicating that folks will use (and use > widely) protocols that are less secure than we would like. =20 > The assertion that It must be secure or "it will exist only=20 > in *islands*"=20 > does not match the observable history. Here less secure stuff within the islands is guranteed by the owner of the domain. Within the enterprises or the providers doing peering do the policy enforcements etc to make sure it is secure. They peer with the known IP addresses at the edge (with ACL etc) and they do the topology hiding within their network. When they go out to untrusted zones, they go through the Media gateways. Here it is not open internet style stuff. > b) The PSTN is no where near as secure as the description=20 > below pretends. There were and are many known security=20 > issues with SS7, and many ways that hackers could and did get=20 > at information in those systems. Agreed. But still SS7 unsecuirty is not as obvious as that of IP. I don't intend to quote different sources etc. > c) By providing for end-to-end security over and above=20 > hop-by-hop security, the current definitions already allow=20 > for servers and users to offer and utilize significantly more=20 > secure capabilities than have existed heretofore. I don't understand your argument here. Can you explain. If a less secure hop is in between, it looses the purpose of other more secure hops. IP/TLS etc security is dynamic too. It will be always N+1 game. For example can you distinguish between two different TLS version/DTLS etc in the current specifications. > d) Adding extra mechanisms to the protocol to try to detect=20 > very specific cases, with known limitations to those=20 > mechanisms, is not an effective approach to the sorts of=20 > problems you have indicated you would like to see addressed. > e) Much of your argument, if I have read and understood it=20 > properly, is about what proxies might choose to do if they=20 > choose to do a bad job offering security capabilities. While=20 > such a choice is a problem, it is not a protocol definition problem. >=20 Choice is a problem here. But why we defined multiple IP Addresses for reaching a domain in the protocol itself. There would have been no need to specify SRV records etc. If the one route and one Proxy (at one IPAddress) is always working. Protocols have been designed to take care of availability e.g. VRRP. Proxies / Administrators do commit mistakes. It will be very similar to current zombie scanning by email spammers. When attackers find less secure hop, they can find lot of stuff. Refer my earlier comment on the moving security definition in IP itself. TLS itelf has two versions currently. When 3261 was written, we mandated only AES128 and we have AES256 also. We need to have a future proof stuff also apart from Trust and Verification as explained.=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 10:07:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASD1-00085y-AX; Tue, 08 Aug 2006 10:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASCz-00085r-OT for sip@ietf.org; Tue, 08 Aug 2006 10:05:25 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GASCy-0003FI-D2 for sip@ietf.org; Tue, 08 Aug 2006 10:05:25 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 08 Aug 2006 07:05:23 -0700 X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="1845161222:sNHT26948940" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78E5NGY025626; Tue, 8 Aug 2006 07:05:23 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k78E5NIZ021252; Tue, 8 Aug 2006 07:05:23 -0700 (PDT) Received: from [10.32.245.150] (stealth-10-32-245-150.cisco.com [10.32.245.150]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k78Dvjei032582; Tue, 8 Aug 2006 06:57:46 -0700 In-Reply-To: <079e01c6ba4b$49058590$6601a8c0@acmepacket.com> References: <079e01c6ba4b$49058590$6601a8c0@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Tue, 8 Aug 2006 10:05:12 -0400 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-6.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1814; t=1155045923; x=1155909923; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20rosenberg-sip-identity-coexistence; X=v=3Dcisco.com=3B=20h=3DCKTqMJaXBDJScvy6cNgnvNoKgA4=3D; b=l2+WY2KmR7no7mA/Excrml0czI8Lmdwmss8FnL5Mp2OnftpGn5hyRNkplqOuBHyTJIuIYDFl UX10wV5lx9y4+C8YMGRgEuTekZiouVGbhe7ZxxMqV941M5z6gPmPKGWL; X-Spam-Score: 1.1 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 'Cullen Jennings' , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 7, 2006, at 1:59 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: David R Oran [mailto:oran@cisco.com] >> Sent: Wednesday, August 02, 2006 10:30 AM >> >> On Aug 1, 2006, at 7:19 PM, Hadriel Kaplan wrote: >> >>> So then my problem is A-B-C-D. C passes the request to D. C did >>> not own a >>> b2bua, and did not need to re-sign it. So D gets a request that >>> still has >>> B's signature, and A's From URI domain. Why should D believe B's >>> signature, >>> when it only has a relationship to C? >>> >> Transitive trust. D has to assume C checked B's signature and was >> satisfied enough to re-initiate the SIP dialog it got from B. > > Yup, so then we're back to pre-Identity, because D makes that > assumption > right now. D has no idea if C does any verifying, or supports > identity. > > >>> I think the answer is "it shouldn't". So my problem is how will we >>> get this >>> mechanism off the ground, when the most applicable/beneficial use >>> cases for >>> it (multi-domain transit) won't work? I am unconvinced it has any >>> tangible >>> value other than multi-domain cases. >>> >> I'm unconvinced why we need to support transit in the first place, >> but that's another can of very large and aggressive c.elegans. > > (hey, at least c.elegans are well-studied and understood ;-) > > If we don't support transit, why do we need an Identity-type > mechanism? > For retargeting. > -hadriel > > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 08 10:39:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASiN-0007Zk-Dq; Tue, 08 Aug 2006 10:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASiL-0007Zf-Tv for sip@ietf.org; Tue, 08 Aug 2006 10:37:49 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GASiJ-0008Lo-GT for sip@ietf.org; Tue, 08 Aug 2006 10:37:49 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k78EbgF18595; Tue, 8 Aug 2006 07:37:42 -0700 Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <97c6675b2ee51583a60a7c68b79f8810@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 8 Aug 2006 07:38:03 -0700 To: IETF SIP List X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Rohan Mahy Subject: [Sip] Summary of draft-ietf-sip-outbound Issues X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, My apologies for taking so long to get this out. At our meeting in Montreal, I presented slides on issues related to draft-ietf-sip-outbound. Here is a summary of what's happening with each of these. If you have questions, please respond to the appropriate thread for each issue (or start a new thread if you have a new issue). Slides can be found here: http://www3.ietf.org/proceedings/06jul/slides/sip-5.pdf thanks, -rohan Slide 1: title slide Slide 2: Reregistering too rapidly: I will send out a separate mail describing this issue. Reregistering immediately if there have been mulitple flow failures in a short period of time (ex: 30 seconds) is also problematic if a NAT is rebooting over and over again. Slides 3 and 4: SIP STUN discovery and validation: I have sent out a separate email on this issue. To summarize the proposal, the UAC adds Proxy-Require: sip-stun, which the first proxy removes. Supported: outbound implies that either the registrar supports SIP stun or expects to never receive a request without getting it from outbound proxy. slide 7: Additional outbound discovery mechanisms Sent email confirming that we are declaring additional outbound discovery out of scope. there is not even a consensus on use cases and requirements. slides 9 and 10: How to tell if edge proxy supports outbound, and what does Supported: outbound mean? Sent email to test my proposal on the list (same proposal as described in slides). slide 11: Semantics of reg-id: replacement? Sent email to confirm on the list that registration with same reg-id *replaces* flows Slide 5: Where does STUN keepalive description go Keith sent a separate mail to the list on this proposing that the description lives in an autonomous section of the outbound draft. In addition we agreed to the following (overwhelming consensus): slide 6: Agreed to change draft so you SHOULD register for each URI in outbound-proxy-set slide 8: Agreed to reword language about EP and authorization policy slide 12: Editors will clarify that normally you should reregister over the same flow as original registration slide 13: Editors will change 410 Gone to 480 Temporarily Unavailable _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 10:40:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASj5-0007mj-NG; Tue, 08 Aug 2006 10:38:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASj3-0007md-Ph for sip@ietf.org; Tue, 08 Aug 2006 10:38:33 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GASj2-0008NZ-DB for sip@ietf.org; Tue, 08 Aug 2006 10:38:33 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k78EcRF18606; Tue, 8 Aug 2006 07:38:27 -0700 Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 8 Aug 2006 07:38:52 -0700 To: IETF SIP List X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Rohan Mahy Subject: [Sip] Outbound Issues: slides 3 and 4 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We had a very long discussion in Montreal about discovery and validation of a SIP outbound proxy server's ability to receive STUN requests. While the vast majority of the room was comfortable that "keepalive=stun" in a URI was a sufficient indicator that an outbound proxy supports SIP and STUN over the same port, a small but extremely vocal minority had significant problems with this assumption. After a discussion with Dean, I am willing to try a validation proposal which adds no extra round trips if the SIP UA was indeed correctly configured. The specific proposal works like this. A UAC which has an outbound URI indicating with ;keepalive=stun that the next hop can support STUN messages on the SIP port, needs to verify the first hop supports STUN before sending any STUN messages. The UAC sends its first SIP message to the next hop with a Proxy-Require: sip-stun. If the URI was correct (STUN was supported), and the first-hop is an intermediary, the first-hop removes the Proxy-Require and forwards the SIP request (probably a REGISTER request) along adding no additional delay. A positive response to a REGISTER or OPTIONS with Supported: outbound and no error counts as positive confirmation that either the registrar supports STUN or expects to never receive a request without getting it from an outbound proxy which did not complain about the Proxy-Require [1]. If the UAC was misconfigured (the first-hop intermediary does not support STUN keepalives), either the first hop will reject the SIP request (if it is an intermediary), or the registrar will not include an indicator that it supports outbound (if the first hop was the registrar). Note that this proposal is not a full *discovery* mechanism, just a verification mechanism. For example, if the registrar doesn't support outbound, but the first-hop does, there is no way described here to discover that the first-hop can accept STUN keepalives. Do not confuse support of STUN with support of outbound. Supported: outbound implies that the registrar supports STUN or is configured to use an outbound proxy that does. The sip-stun option tag only means that you can send and receive STUN requests on your SIP port. While outbound requires STUN, STUN does not require outbound. [1] Also Note that there is a caveat that you can still shoot yourself in the foot if you allow messages to come straight to your registrar that does not support STUN. I think we agreed that we are not going to enumerate all the ways you can subtly break things in SIP though. thanks, -rohan _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 10:40:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASj9-0007tp-Hc; Tue, 08 Aug 2006 10:38:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASj8-0007t1-AM for sip@ietf.org; Tue, 08 Aug 2006 10:38:38 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GASj6-0008PF-Ue for sip@ietf.org; Tue, 08 Aug 2006 10:38:38 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k78EcVF18610; Tue, 8 Aug 2006 07:38:31 -0700 Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <66065d2102228767d3d785ee703e4bc7@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 8 Aug 2006 07:38:55 -0700 To: IETF SIP List X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Rohan Mahy Subject: [Sip] Outbound issues: slide 7 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I believe we have broad agreement that the new mechanisms to discover an outbound-proxy-set (or related data used to derive the outbound-proxy-set) are out of scope of the outbound draft. Currently there is not even a consensus on use cases and requirements for such a discovery mechanism. thanks, -rohan _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 10:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASjE-00083s-IQ; Tue, 08 Aug 2006 10:38:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASjC-00081N-TA for sip@ietf.org; Tue, 08 Aug 2006 10:38:42 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GASjB-0008Pr-HB for sip@ietf.org; Tue, 08 Aug 2006 10:38:42 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k78EcbF18629; Tue, 8 Aug 2006 07:38:37 -0700 Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <709599f70080d8e37136d1f1d254ac11@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 8 Aug 2006 07:39:01 -0700 To: IETF SIP List X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Rohan Mahy Subject: [Sip] Outbound issues: slide 11 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We discussed that the intended semantics of reg-id were to allow a client to *replace* an earlier registration with the same reg-id. These semantics got rather confused during subsequent versions of the draft causing some inconsistencies and a lot of puzzled reader. I proposed going back to the original semantics. We had consensus in the room to do this. Keith asked me to confirm that this consensus still holds on the list. thanks, -rohan _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 10:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASjD-00081S-FT; Tue, 08 Aug 2006 10:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASjB-0007zS-8D for sip@ietf.org; Tue, 08 Aug 2006 10:38:41 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GASj9-0008PM-3N for sip@ietf.org; Tue, 08 Aug 2006 10:38:40 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k78EcYF18619; Tue, 8 Aug 2006 07:38:34 -0700 Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6c91a88d048a5acea156de16a7f4fe44@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 8 Aug 2006 07:38:58 -0700 To: IETF SIP List X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Rohan Mahy Subject: [Sip] Outbound issues: slides 9 and 10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The issues on slide 9 (how does a registrar verify that an edge proxy supports outbound) and slide 10 (what does "Supported: outbound" mean) deal with detecting that all the required hops support outbound. Slide 9 specifically uncovered a problem with outbound proxies that add a Path URI but don't include a flow token. The proposed solution is as follows. If a proxy inserts a Path header with a flow token consistent with the rules described in outbound, it MUST add the ;ob parameter to the proxy URI that has the flow token. The registrar verifies that any Path header URIs contain the ;ob parameter. If there are any Path URIs without the ob parameter, the registrar does not return Supported: outbound. Furthermore, the registrar needs to check that the first hop after the UAC is represented in the Path list (unless the registrar recognizes that the first hop after the UAC is in the same domain and doesn't need to include Path URIs with a flow token). Note that this implies that whatever the proxy puts in the Via (IP address or FQDN), it must put the same hostname in the Path header (but there is no need for a complete URI comparison). If the first hop is not correctly represented, the registrar ignores the reg-id parameter and does not return Supported: outbound. The implication of this is that an outbound-proxy that supports outbound needs to support Path and flow tokens for registrations to all foreign domains. Inside the same domain, the first-hop proxy and the registrar can still use Path to communicate with each other, but they can use some other private mechanism to disaggregate this functionality. thanks, -rohan _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 10:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASjE-00083s-IQ; Tue, 08 Aug 2006 10:38:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASjC-00081N-TA for sip@ietf.org; Tue, 08 Aug 2006 10:38:42 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GASjB-0008Pr-HB for sip@ietf.org; Tue, 08 Aug 2006 10:38:42 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k78EcbF18629; Tue, 8 Aug 2006 07:38:37 -0700 Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <709599f70080d8e37136d1f1d254ac11@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 8 Aug 2006 07:39:01 -0700 To: IETF SIP List X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Rohan Mahy Subject: [Sip] Outbound issues: slide 11 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We discussed that the intended semantics of reg-id were to allow a client to *replace* an earlier registration with the same reg-id. These semantics got rather confused during subsequent versions of the draft causing some inconsistencies and a lot of puzzled reader. I proposed going back to the original semantics. We had consensus in the room to do this. Keith asked me to confirm that this consensus still holds on the list. thanks, -rohan _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 10:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASjD-00081S-FT; Tue, 08 Aug 2006 10:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GASjB-0007zS-8D for sip@ietf.org; Tue, 08 Aug 2006 10:38:41 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GASj9-0008PM-3N for sip@ietf.org; Tue, 08 Aug 2006 10:38:40 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k78EcYF18619; Tue, 8 Aug 2006 07:38:34 -0700 Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6c91a88d048a5acea156de16a7f4fe44@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 8 Aug 2006 07:38:58 -0700 To: IETF SIP List X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Rohan Mahy Subject: [Sip] Outbound issues: slides 9 and 10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The issues on slide 9 (how does a registrar verify that an edge proxy supports outbound) and slide 10 (what does "Supported: outbound" mean) deal with detecting that all the required hops support outbound. Slide 9 specifically uncovered a problem with outbound proxies that add a Path URI but don't include a flow token. The proposed solution is as follows. If a proxy inserts a Path header with a flow token consistent with the rules described in outbound, it MUST add the ;ob parameter to the proxy URI that has the flow token. The registrar verifies that any Path header URIs contain the ;ob parameter. If there are any Path URIs without the ob parameter, the registrar does not return Supported: outbound. Furthermore, the registrar needs to check that the first hop after the UAC is represented in the Path list (unless the registrar recognizes that the first hop after the UAC is in the same domain and doesn't need to include Path URIs with a flow token). Note that this implies that whatever the proxy puts in the Via (IP address or FQDN), it must put the same hostname in the Path header (but there is no need for a complete URI comparison). If the first hop is not correctly represented, the registrar ignores the reg-id parameter and does not return Supported: outbound. The implication of this is that an outbound-proxy that supports outbound needs to support Path and flow tokens for registrations to all foreign domains. Inside the same domain, the first-hop proxy and the registrar can still use Path to communicate with each other, but they can use some other private mechanism to disaggregate this functionality. thanks, -rohan _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 11:23:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATP7-0006jN-UK; Tue, 08 Aug 2006 11:22:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATP6-0006jC-8P for sip@ietf.org; Tue, 08 Aug 2006 11:22:00 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GATP4-0007eK-1V for sip@ietf.org; Tue, 08 Aug 2006 11:22:00 -0400 Received: from [71.240.232.162] (helo=JMHLap3.stevecrocker.com) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GATP3-0004kw-98; Tue, 08 Aug 2006 11:21:57 -0400 Message-Id: <7.0.1.0.0.20060808112042.03f9b318@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 08 Aug 2006 11:21:51 -0400 To: "Samir Srivastava" From: "Joel M. Halpern" Subject: RE: [Sip] Ciphersuites in SIP In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DB33C06@zrc2hxm2.corp.nor tel.com> References: <7.0.1.0.0.20060808022151.03fa6650@stevecrocker.com> <62B9B0847CC47543B6B3B5E26BD268E60DB33C06@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120e26356c0b047047044c686807a6a34ba7c148ff696ae7f78350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.240.232.162 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If an end-point wants real security in communicating with another end-point, it should sign the request it sends. (Yes, that prevents the teleco SBC from changing things. But you can not have end-to-end security and allow devices in the middle to make arbitrary changes.) Yours, Joel M. Halpern At 03:24 AM 8/8/2006, Samir Srivastava wrote: > > c) By providing for end-to-end security over and above > > hop-by-hop security, the current definitions already allow > > for servers and users to offer and utilize significantly more > > secure capabilities than have existed heretofore. > >I don't understand your argument here. Can you explain. If a less secure >hop is in between, it looses the purpose of other more secure hops. >IP/TLS etc security is dynamic too. It will be always N+1 game. For >example can you distinguish between two different TLS version/DTLS etc >in the current specifications. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 12:49:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUjz-0003U7-7W; Tue, 08 Aug 2006 12:47:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAUjy-0003QM-7l for sip@ietf.org; Tue, 08 Aug 2006 12:47:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAUju-0002tw-UX for sip@ietf.org; Tue, 08 Aug 2006 12:47:38 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 08 Aug 2006 09:47:35 -0700 X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="310418480:sNHT24074832" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78GlYD3020163 for ; Tue, 8 Aug 2006 09:47:34 -0700 Received: from [192.168.1.2] (sjc-vpn4-576.cisco.com [10.21.82.64]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k78GlYuD006271 for ; Tue, 8 Aug 2006 09:47:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <44FE358A.4080401@lucent.com> References: <62B9B0847CC47543B6B3B5E26BD268E60DA917E3@zrc2hxm2.corp.nortel.com> <86ejvw5bz3.fsf@raman.networkresonance.com> <44FE358A.4080401@lucent.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Ciphersuites in SIP Date: Tue, 8 Aug 2006 09:47:27 -0700 To: SIP X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=477; t=1155055654; x=1155919654; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Ciphersuites=20in=20SIP; X=v=3Dcisco.com=3B=20h=3DlJdhKimynOyi9tEqS2nMIAz6tCE=3D; b=iZTakdFURz5i8WlxDGXx/xwU/IvPPLEV3900YMu0sLoOLzpPFdal7QgqzDd93++ZTxNLzmTg 8G3wE/DRhkfZQHJXOBkXgeOg7qbXIsIulI8gPD8AEAtrmIa5QYwF2Ypj; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have read this whole thread and I have to admit, I don't understand what people think the problem is that this would solve. One problem I have seen is providing end to end security. I don' see how this could ever do that. The other problem I have seen is that this would stop a proxy from using an TLS cipher on some middle hop that was unacceptable to the UAC. Again, I don't see how this would accomplish that or what piratical problem that solves. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 13:41:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVYl-0005Dv-KP; Tue, 08 Aug 2006 13:40:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVYk-0005Dl-AD for sip@ietf.org; Tue, 08 Aug 2006 13:40:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVYf-0005OX-Mq for sip@ietf.org; Tue, 08 Aug 2006 13:40:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Aug 2006 10:40:00 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="35167994:sNHT24965132" 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.20060308/8.12.11) with ESMTP id k78He07I011989 for ; Tue, 8 Aug 2006 13:40:00 -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.12.10/8.12.6) with ESMTP id k78He0e2018615 for ; Tue, 8 Aug 2006 13:40:00 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 13:40:00 -0400 Received: from [161.44.55.61] ([161.44.55.61]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 13:39:59 -0400 Message-ID: <44D8CC6E.80908@cisco.com> Date: Tue, 08 Aug 2006 13:39:58 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DA917E3@zrc2hxm2.corp.nortel.com> <86ejvw5bz3.fsf@raman.networkresonance.com> <44FE358A.4080401@lucent.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2006 17:40:00.0026 (UTC) FILETIME=[ABF24FA0:01C6BB11] DKIM-Signature: a=rsa-sha1; q=dns; l=3732; t=1155058800; x=1155922800; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Ciphersuites=20in=20SIP |To:Cullen=20Jennings=20; X=v=3Dcisco.com=3B=20h=3DjqGAhJxwefnsCSplnA6V07J2j38=3D; b=c0SzoKyRUl5mA3RGNv7POMYSzE0b4gq1YXrsIKtzwKoL0vdBbWdH4PiaTclH9tPeIEup96xb xtu09iPyEpuXrtY9VtzMJvUGECoQLOXsCnWL/t9y9AOwNeE4XKBp6XMx; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I just read this whole thread, and I think there are multiple problems being discussed here. 1. A proxy is misconfigured to use the wrong ciphersuite. How do we detect and fix this? 2. A malicious proxy has used an inadequate ciphersuite. How do we detect this? 3. How does a caller ensure that a call does not go through unless all proxies along the chain are using suffiently strong ciphersuites? You can break this into two subcases: a. misconfigured proxies b. malicious proxies Firstly, I believe it is not useful to try and solve any problem related to malicious proxies. It is probably far easier for the proxy to just send a cleartext copy of a message somewhere, including spammers and other nefarious bad guys, than it is to just use a lower grade cipher. Consequently, I believe we should discard any use cases related to malicious proxies. So, considering further misconfigured proxies. I personally remain unconvinced that this form of misconfiguration is common at all. Furthermore, of all of the misconfigurations that can happen, this hardly seems like the worst that can happen. Misrouting is far more disruptive to user experience, for example, and a very common configuration error. I also think its important to separate out detction of this misconfiguration, from preventing of a call going forward if this misconfiguration exists. I think the latter is not so important. If you have a mecahnism to help diagnose this kind of misconfiguration, then as long as its eventually fixed, I do not see a strong need to prevent calls from happening if the network is misconfigured in this way. Indeed, there are lots of ways misconfiguration can cause a message to be visible to attackers. For example a far better one is when logging is enabled on a proxy, and there is no encryption of the logging messages to the logging server. Ditto for accounting or QoS authorization. Misconfiguration of the address of an accounting server could cause such accounting messages to even leave the network entirely. For detection of the misconfiguration, I would much rather see us revive Jiri's old diagnostic message, which would allow a test call to be sent which reports what happened at each proxy. This includes the much-more-important routing behavior, but could also report the selected ciphersuites, accounting interfaces used and their security, and so on. This would be a reasonable feature of a diagnostic tool, IMHO. -Jonathan R. Cullen Jennings wrote: > > I have read this whole thread and I have to admit, I don't understand > what people think the problem is that this would solve. > > One problem I have seen is providing end to end security. I don' see > how this could ever do that. > > The other problem I have seen is that this would stop a proxy from > using an TLS cipher on some middle hop that was unacceptable to the > UAC. Again, I don't see how this would accomplish that or what > piratical problem that solves. > > > > _______________________________________________ > Sip mailing list https://www1.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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 13:55:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVlf-0004SY-QH; Tue, 08 Aug 2006 13:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVle-0004ST-T6 for sip@ietf.org; Tue, 08 Aug 2006 13:53:26 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVlb-0007S4-KD for sip@ietf.org; Tue, 08 Aug 2006 13:53:26 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k78HrIe18574; Tue, 8 Aug 2006 13:53:19 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 8 Aug 2006 12:53:15 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB343BF@zrc2hxm2.corp.nortel.com> In-Reply-To: <44D8CC6E.80908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca7EjoVm1tDNJmiSIenpjcZcMOS/AAALEBg From: "Samir Srivastava" To: "Jonathan Rosenberg" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, I will digest other comments and reply later. But for the below one, please find the response below in-line. Thx Samir =20 >=20 > For detection of the misconfiguration, I would much rather see us revive > Jiri's old diagnostic message, which would allow a test call to be sent > which reports what happened at each proxy. This includes the > much-more-important routing behavior, but could also report the selected > ciphersuites, accounting interfaces used and their security, and so on. > This would be a reasonable feature of a diagnostic tool, IMHO. > How can you make sure that your test call traverses the same set of proxies as that of the actual call due to alternate routes, booting proxies etc. It is just the game of chances. If cipher-suites etc are not exposed in via and UAC wished cipher-suites in a separate header, your diagnostic tool is not going to work. =20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 14:00:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVrB-0007Z4-V4; Tue, 08 Aug 2006 13:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAVrA-0007Yz-6C for sip@ietf.org; Tue, 08 Aug 2006 13:59:08 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAVr8-00083L-Qy for sip@ietf.org; Tue, 08 Aug 2006 13:59:08 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-1.cisco.com with ESMTP; 08 Aug 2006 10:59:06 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78Hx6L4028040; Tue, 8 Aug 2006 10:59:06 -0700 Received: from [192.168.1.2] (sjc-vpn4-576.cisco.com [10.21.82.64]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k78Hx6uD011440; Tue, 8 Aug 2006 10:59:06 -0700 (PDT) In-Reply-To: <44C65B13.5040803@cisco.com> References: <44C65B13.5040803@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <859ABDC3-E051-48EB-9D93-C3B4EE3CE515@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Hitchhikers guide - when is it done? Date: Tue, 8 Aug 2006 10:58:59 -0700 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1825; t=1155059946; x=1155923946; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Hitchhikers=20guide=20-=20when=20is=20it=20done?; X=v=3Dcisco.com=3B=20h=3D1GULskCGJ4Q9/rir0qsdtInD44g=3D; b=Mlk1/vZnm70hK1x/v+lKlMGOSOmQBxSm8UWEtW+NVsTcAxq0n5fnukB1gOaxveSw4e9PR7lY EY6guvmDnKoMnyyswbD7pARxGMnKSR42So+aA1mOf6hrZqAOZ03fCQ3R; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I like 2. I can imagine us being able to update this once a year or so ... On Jul 25, 2006, at 10:55 AM, Jonathan Rosenberg wrote: > During the IETF meeting, I discussed the one current open issue in > the Hitchhikers guide. The issue is: when does the document finish? > When do we send to IESG to issue an RFC? > > There were two approaches: > > 1. split the document in two. One part contains only the core > specs, and issues relatively soon. The other part has everything > else, and basically ends up being the last RFC produced by the SIP > WG before it shuts its doors (which has always been 1.5 years from > now for the last 5 years). > > 2. keep it as one document. Issue an RFC at some point, and then > revise it a few times as needed. We need to decide when to issue it. > > > I'd like to propose option 2. I think people get more value from it > as a consolidated document. Furthermore, I'd propose that we send > the document to IESG for consideration as informational at the > instant all of the documents listed as 'core' have RFC numbers > issued by RFC-ed. > > Comments? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 08 14:48:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWbJ-0007mw-Gt; Tue, 08 Aug 2006 14:46:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWbI-0007mr-7J for sip@ietf.org; Tue, 08 Aug 2006 14:46:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAWbF-0005Fw-OZ for sip@ietf.org; Tue, 08 Aug 2006 14:46:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Aug 2006 11:46:45 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="35180288:sNHT23631192" 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.20060308/8.12.11) with ESMTP id k78IkjNa013379; Tue, 8 Aug 2006 14:46:45 -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.12.10/8.12.6) with ESMTP id k78Ikie2009027; Tue, 8 Aug 2006 14:46:45 -0400 (EDT) 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); Tue, 8 Aug 2006 14:46:44 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 14:46:44 -0400 Message-ID: <44D8DC12.8090806@cisco.com> Date: Tue, 08 Aug 2006 14:46:42 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samir Srivastava Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DB343BF@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DB343BF@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2006 18:46:44.0693 (UTC) FILETIME=[FEEA0050:01C6BB1A] DKIM-Signature: a=rsa-sha1; q=dns; l=1977; t=1155062805; x=1155926805; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Ciphersuites=20in=20SIP |To:Samir=20Srivastava=20; X=v=3Dcisco.com=3B=20h=3DjqGAhJxwefnsCSplnA6V07J2j38=3D; b=fedfdq/nXVHmimWcH0pg9Rb8W32YgK2qJp0vYnRWIZjV5Qsci5pfiubiV17KdVj8bhaBlTFR Ru+Fce6j1cWPvCHo0o0Zw/4AgSXKwVO04+jY/4VgJsVJKPZ7iBqXFEAa; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Cullen Jennings , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sure - call trace tools don't catch all problems. There are many techniques that are used to handle configuration problems. For example, audits and analyses on logs, tools that read and validate configurations across components based on criteria, and so on. Several of these would almost always catch this kind of problem. My point is that I don't see the need to develop a new protocol mechanism to fix one very specific, not very common, not very-bad proxy misconfiguration. I'd rather develop tools that try and help troubleshoot SIP networks across a broader set of problems. Thanks, Jonathan R. Samir Srivastava wrote: > Hi Jonathan, > > I will digest other comments and reply later. But for the below one, > please find the response below in-line. > > Thx > Samir > > >>For detection of the misconfiguration, I would much rather see us > > revive > >>Jiri's old diagnostic message, which would allow a test call to be > > sent > >>which reports what happened at each proxy. This includes the >>much-more-important routing behavior, but could also report the > > selected > >>ciphersuites, accounting interfaces used and their security, and so > > on. > >>This would be a reasonable feature of a diagnostic tool, IMHO. >> > > > How can you make sure that your test call traverses the same set of > proxies as that of the actual call due to alternate routes, booting > proxies etc. It is just the game of chances. > > If cipher-suites etc are not exposed in via and UAC wished cipher-suites > in a separate header, your diagnostic tool is not going to work. > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 14:48:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWbT-0007sq-Ad; Tue, 08 Aug 2006 14:46:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWbR-0007qf-Op for sip@ietf.org; Tue, 08 Aug 2006 14:46:57 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAWbP-0005GM-Bp for sip@ietf.org; Tue, 08 Aug 2006 14:46:57 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k78IkqF26344; Tue, 8 Aug 2006 14:46:52 -0400 (EDT) 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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Tue, 8 Aug 2006 13:46:33 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0C184D04@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 thread-index: Aca6+FvmrwPGJkN2QEeK2pW3HBAA0wAGTe/A From: "Francois Audet" To: "Rohan Mahy" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan, I really like the idea of decoupling sip-stun support, versus outbound support. But I'm findind the description quite complicated... I'm also wondering if the ";keep-alive=3Dstun" is still useful with the=20 addition of the Proxy-Require: sip-stun. It doesn't seem=20 to me that it is, except as an automatic configuration option for the UAC. Since the UAC certainly requires much more configuration options (with=20 config-framework, or config files or whatever), I'm not sure it is worth the effort. I don't see why this one in particular is more important than any other. Let me try to paraphrase what you are saying, to make sure I understood it properly: - "Proxy-require: sip-stun" means that the outbound proxy is required to support sip-stun, i.e., the procedures of section 3.5. A consequence of this is that it precludes deployments where the sip-stun is supported not in the first hop, but later (e.g., the Registrar), but with some other intermedia proxy between. - "Supported: outbound" means that the Registrar supports the procedures of the draft that are not related to sip-stun. - ";keep-alive=3Dstun" is an indication for the UAC that stun-in-sip is supported by the network. Essentially an autoconfiguration option. We have been using terms like "edge proxy", "outbound proxy" now "first hop",=20 and "intermediary". To me, it seems that there are only two entities that are relevant here: 1 - The outbound proxy. This is where all requests are sent, and the entity that terminates sip-in-stun. 2 - The Registrar. Also the entity that supports the "Outbound" procedures (excluding stun-in-sip). A very common scenario is where 1 & 2 are co-located. In this case the Registrar is the oubound-proxy and it does terminate sip-stun. Also, I don't understand why your point [1] is a problem. Wouldn't a Registrar that doesn't support stun-sip, but which is accesses directly (i.e., as an outbound proxy) just reject the REGISTER because it contained "Proxy-Require: stun-sip" with=20 420 with "Unsupported: stun-sip"? Are you worried that such a REGISTRAR may not believe the Proxy-Require was intended for itself? > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com]=20 > Sent: Tuesday, August 08, 2006 7:39 AM > To: IETF SIP List > Cc: Rohan Mahy > Subject: [Sip] Outbound Issues: slides 3 and 4 >=20 >=20 > We had a very long discussion in Montreal about discovery and=20 > validation of a SIP outbound proxy server's ability to=20 > receive STUN requests. While the vast majority of the room=20 > was comfortable that "keepalive=3Dstun" in a URI was a=20 > sufficient indicator that an outbound proxy supports SIP and=20 > STUN over the same port, a small but extremely vocal minority=20 > had significant problems with this assumption. After a=20 > discussion with Dean, I am willing to try a validation=20 > proposal which adds no extra round trips if the SIP UA was=20 > indeed correctly configured. >=20 > The specific proposal works like this. A UAC which has an=20 > outbound URI indicating with ;keepalive=3Dstun that the next=20 > hop can support STUN messages on the SIP port, needs to=20 > verify the first hop supports STUN before sending any STUN=20 > messages. The UAC sends its first SIP message to the next hop=20 > with a Proxy-Require: sip-stun. If the URI was correct (STUN=20 > was supported), and the first-hop is an intermediary, the=20 > first-hop removes the Proxy-Require and forwards the SIP=20 > request (probably a REGISTER request) along adding no=20 > additional delay. A positive response to a REGISTER or=20 > OPTIONS with Supported: outbound and no error counts as=20 > positive confirmation that either the registrar supports STUN=20 > or expects to never receive a request without getting it from=20 > an outbound proxy which did not complain about the=20 > Proxy-Require [1]. If the UAC was misconfigured (the=20 > first-hop intermediary does not support STUN keepalives),=20 > either the first hop will reject the SIP request (if it is an=20 > intermediary), or the registrar will not include an indicator=20 > that it supports outbound (if the first hop was the registrar). >=20 > Note that this proposal is not a full *discovery* mechanism,=20 > just a verification mechanism. For example, if the registrar=20 > doesn't support outbound, but the first-hop does, there is no=20 > way described here to discover that the first-hop can accept=20 > STUN keepalives. Do not confuse support of STUN with support=20 > of outbound. Supported: outbound implies that the registrar=20 > supports STUN or is configured to use an outbound proxy that=20 > does. The sip-stun option tag only means that you can send=20 > and receive STUN requests on your SIP port. While outbound=20 > requires STUN, STUN does not require outbound. >=20 > [1] Also Note that there is a caveat that you can still shoot=20 > yourself in the foot if you allow messages to come straight=20 > to your registrar that does not support STUN. I think we=20 > agreed that we are not going to enumerate all the ways you=20 > can subtly break things in SIP though. >=20 > thanks, > -rohan >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 14:50:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWcj-0000nj-CZ; Tue, 08 Aug 2006 14:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWci-0000nU-C5 for sip@ietf.org; Tue, 08 Aug 2006 14:48:16 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAWcg-0005PI-0d for sip@ietf.org; Tue, 08 Aug 2006 14:48:16 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Aug 2006 11:48:13 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="35180523:sNHT27100562" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78ImDpD014044 for ; Tue, 8 Aug 2006 14:48:13 -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.12.10/8.12.6) with ESMTP id k78ImDdp003922 for ; Tue, 8 Aug 2006 14:48:13 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 14:48:13 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 14:48:13 -0400 Message-ID: <44D8DC6B.6000203@cisco.com> Date: Tue, 08 Aug 2006 14:48:11 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Hitchhikers guide - when is it done? References: <44C65B13.5040803@cisco.com> <859ABDC3-E051-48EB-9D93-C3B4EE3CE515@cisco.com> In-Reply-To: <859ABDC3-E051-48EB-9D93-C3B4EE3CE515@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2006 18:48:13.0031 (UTC) FILETIME=[33914F70:01C6BB1B] DKIM-Signature: a=rsa-sha1; q=dns; l=2352; t=1155062893; x=1155926893; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Hitchhikers=20guide=20-=20when=20is=20it=20done? |To:Cullen=20Jennings=20; X=v=3Dcisco.com=3B=20h=3DDpAaA9rWoxuoASPdrDDBO7lqI1E=3D; b=Jr98Sm7frLW24cfo7BXDjkLwRDDvKbLZVq4VkXLPCvniBPqepgThJI1YiP99J2LmugWKXzi3 lSpjzqp9K8fpt1Ddzgsc3Dd/TJwohJl3agu3a5P7cbQsCJrEIV3buowZ; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for the input. I think there was general consensus on this approach, with a once-a-year update. Thanks, Jonathan R. Cullen Jennings wrote: > > I like 2. I can imagine us being able to update this once a year or so ... > > On Jul 25, 2006, at 10:55 AM, Jonathan Rosenberg wrote: > >> During the IETF meeting, I discussed the one current open issue in >> the Hitchhikers guide. The issue is: when does the document finish? >> When do we send to IESG to issue an RFC? >> >> There were two approaches: >> >> 1. split the document in two. One part contains only the core specs, >> and issues relatively soon. The other part has everything else, and >> basically ends up being the last RFC produced by the SIP WG before it >> shuts its doors (which has always been 1.5 years from now for the >> last 5 years). >> >> 2. keep it as one document. Issue an RFC at some point, and then >> revise it a few times as needed. We need to decide when to issue it. >> >> >> I'd like to propose option 2. I think people get more value from it >> as a consolidated document. Furthermore, I'd propose that we send the >> document to IESG for consideration as informational at the instant >> all of the documents listed as 'core' have RFC numbers issued by RFC-ed. >> >> Comments? >> >> -Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> Sip mailing list https://www1.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 > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 14:53:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWg5-0003DI-VY; Tue, 08 Aug 2006 14:51:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAWg3-00036j-OC for sip@ietf.org; Tue, 08 Aug 2006 14:51:43 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAWg2-0005cJ-Ew for sip@ietf.org; Tue, 08 Aug 2006 14:51:43 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k78IpeF26820 for ; Tue, 8 Aug 2006 14:51:40 -0400 (EDT) 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 Subject: FW: [Sip] SIP Over UDP and DTLS Date: Tue, 8 Aug 2006 13:51:39 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB34528@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Over UDP and DTLS Thread-Index: AcayGJcNlHshGJoCRyuWXiHGFZOerwAAjGWAAkAd4uA= From: "Samir Srivastava" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I didn't see any comments on the below. Where we stand on the need for DTLS? Thx Samir -----Original Message----- From: Srivastava, Samir (SC100:8826)=20 Sent: Friday, July 28, 2006 1:02 AM To: sip@ietf.org Subject: [Sip] SIP Over UDP Hi, I have been earlier proposing to deprecate the SIP over UDP and there have been arguments about the large SDP etc. It will be useful for Page Mode IM, where we will be sending short IM. Hence we might need DTLS too. Should we still deprecate it.. Rajnish was arguing that one can cut and paste long text in the body too. If it is so, then client can use TCP or TLS based on the size. Thx Samir _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 08 15:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAX1z-0005r4-Qu; Tue, 08 Aug 2006 15:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAX1y-0005qz-Cf for sip@ietf.org; Tue, 08 Aug 2006 15:14:22 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAX1x-0006zp-1j for sip@ietf.org; Tue, 08 Aug 2006 15:14:22 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k78JEHY01758; Tue, 8 Aug 2006 15:14:17 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 8 Aug 2006 14:14:16 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB3459E@zrc2hxm2.corp.nortel.com> In-Reply-To: <44D8DC12.8090806@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca7G1HJI4M3TgdvTHygvtS9yL1ccgAAkyXQ From: "Samir Srivastava" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Cullen Jennings , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, Well, for the tool itself to work, we need to have the proposed extensions. Only looking into the log info is not sufficient? When one should look and from which proxies etc in the real life deployment scenarios is difficult.=20 How can we differentiate 3DES (from the old ones), AES128 (3261), and AES256 another new cipher-suite? They have different levels. They need to be exposed irrespective of configuration errors etc.=20 It should be noted that MTA add cipher-suite info too.=20 Thx Samir > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Tuesday, August 08, 2006 11:47 AM > To: Srivastava, Samir (SC100:8826) > Cc: Cullen Jennings; SIP > Subject: Re: [Sip] Ciphersuites in SIP >=20 > Sure - call trace tools don't catch all problems. There are many > techniques that are used to handle configuration problems. For example, > audits and analyses on logs, tools that read and validate configurations > across components based on criteria, and so on. Several of these would > almost always catch this kind of problem. >=20 > My point is that I don't see the need to develop a new protocol > mechanism to fix one very specific, not very common, not very-bad proxy > misconfiguration. I'd rather develop tools that try and help > troubleshoot SIP networks across a broader set of problems. >=20 > Thanks, > Jonathan R. >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 15:21:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAX7a-0002GV-Uq; Tue, 08 Aug 2006 15:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAX7Z-0002GQ-9O for sip@ietf.org; Tue, 08 Aug 2006 15:20:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAX7X-0007Ub-T0 for sip@ietf.org; Tue, 08 Aug 2006 15:20:09 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 08 Aug 2006 15:20:07 -0400 X-IronPort-AV: i="4.07,222,1151899200"; d="scan'208"; a="95727320:sNHT27644572" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78JK7sY029175; Tue, 8 Aug 2006 15:20:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k78JK7dp013784; Tue, 8 Aug 2006 15:20:07 -0400 (EDT) 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, 8 Aug 2006 15:20:07 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 15:20:07 -0400 Message-ID: <44D8E3E5.5000205@cisco.com> Date: Tue, 08 Aug 2006 15:20:05 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] draft-ietf-sip-gruu-10.txt References: <200608041322.k74DMaA5009472@dragon.ariadne.com> In-Reply-To: <200608041322.k74DMaA5009472@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2006 19:20:07.0082 (UTC) FILETIME=[A86E50A0:01C6BB1F] DKIM-Signature: a=rsa-sha1; q=dns; l=4695; t=1155064807; x=1155928807; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-gruu-10.txt |To:Dale.Worley@comcast.net; X=v=3Dcisco.com=3B=20h=3DU9jGmPjZg8iRWw1dHYAKux8espI=3D; b=Us2ozARmCbGT85FSKHj4XpZ4Pf3MWQxIWzHkAgYZ8LcJ+T4JA4XtvcV20nPhoWsMkaaJIg6q f3stPaQsd952ZBJJGtvoun3f0mgn9ufp1bXQ44NIEkQTqHQBt/W3/Z0p; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for the comments. More inline. Dale.Worley@comcast.net wrote: > I read section 8 of the -10 draft to see if certain passages I'd been > having trouble understanding had been resolved, and I ran into the > following difficulties: > > In 8.2.2, I see "The rules in Section 8.1.1 ensure that at least one > proxy in the same domain of the home proxy will be visited." In the > context, it appears that this is stating that 8.1.1 ensures that a UA > in a domain that issues GRUUs will always have its UAs use an outbound > proxy. And yet I can't see how 8.1.1 forces that, especially in light > of the statement "Note that this specification does not require the > use of an outbound proxy". This is a bug. It should say that, if an outbound proxy is used at all, then the request will visit a proxy in the home domain. But, its valid to use gruu without any outbound proxies. > > And some wording issues: > > When using a service route, > this requirement (that the GRUU be obtained from a domain that will > be visited by the request) it is sufficient to use the GRUU learned > in the same registration that delivered the service route. > > This doesn't parse. Possibly it should read "... to satisfy this > requirement (...), it is sufficient ...". My bad. How about: When using a service route, this requirement (that the GRUU be obtained from a domain that will be visited by the request) is readily met by using the GRUU learned in the same REGISTER response that delivered the service route. > > Note that this specification does not require the use of an outbound > proxy; it merely introduces the previous requirements in cases where > one is used. > > I think that "previous" won't be read as intended, as I interpreted it > to mean "backward in time (to RFC 3261)", not "the previous paragraph > in this document". How about "...; but in cases where one is used, it > adds the above requirements."? Changed to: Note that this specification does not require the use of an outbound proxy; the behaviors defined in the previous paragraph only apply in cases where one is used. > > The > rules in Section 8.1.1 ensure that at least one proxy in the same > domain of the home proxy will be visited. > > "the same domain of" s.b. "the domain of". Fixed. > > Also, this entire paragraph is written in reverse logical sequence. > IMHO, it's better to give causes before effects, even if that delays > stating the requirement itself: > > Firstly: The rules in Section 8.1.1 ensure that at least one proxy > in the same domain of the home proxy will be visited. A home proxy > can use mechanisms such as Service-Route [27] or UA configuration > to ensure that it, or a proxy in the same domain, is on the > outgoing request path. If such a proxy receives a dialog forming > request from a UA in its own domain (an originating request) whose > Contact header field contains a GRUU (indicated by the presence of > the "gruu" URI parameter) that is also in that domain, the proxy > MUST generate a record-route which will route to the home proxy. OK. I reworded thusly: There are two distinct requirements for record-routing - in the originating domain and in the terminating domain. This specification does not require that a UA use an outbound proxy, in which case a dialog forming request may not visit any proxies in the originating domain. However, if the UA is using an outbound proxy, the rules in require that at least one proxy in the domain of the home proxy be visited. A home proxy can use mechanisms such as Service-Route or UA configuration to ensure that it, or a proxy in the same domain, is on the outgoing request path. If such a proxy receives a dialog forming request from a UA in its own domain (an originating request) whose Contact header field contains a GRUU (indicated by the presence of the "gruu" URI parameter) that is also in that domain, the proxy MUST generate a record-route which will route to the home proxy. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 15:26:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXBm-0003S6-RM; Tue, 08 Aug 2006 15:24:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXBm-0003S1-4j for sip@ietf.org; Tue, 08 Aug 2006 15:24:30 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAXBj-0007gj-Rj for sip@ietf.org; Tue, 08 Aug 2006 15:24:30 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Aug 2006 12:24:26 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="35186709:sNHT23657272" 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.20060308/8.12.11) with ESMTP id k78JOQLL032701; Tue, 8 Aug 2006 15:24:26 -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.12.10/8.12.6) with ESMTP id k78JOPdp015063; Tue, 8 Aug 2006 15:24:25 -0400 (EDT) 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); Tue, 8 Aug 2006 15:24:25 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 15:24:25 -0400 Message-ID: <44D8E4E7.9060801@cisco.com> Date: Tue, 08 Aug 2006 15:24:23 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samir Srivastava Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DB3459E@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DB3459E@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2006 19:24:25.0543 (UTC) FILETIME=[427C5570:01C6BB20] DKIM-Signature: a=rsa-sha1; q=dns; l=1371; t=1155065066; x=1155929066; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Ciphersuites=20in=20SIP |To:Samir=20Srivastava=20; X=v=3Dcisco.com=3B=20h=3DjqGAhJxwefnsCSplnA6V07J2j38=3D; b=XtwFRtLUbBxXm/PNM+dAotL9LfJIup2gcA9/5p4tbirkDLLBHfk0zKBy01XrVQBYPkD+d1Dy LBxtswQkI3Aa2obtE37Vc89yaKuk469Q/nIRIl0xaBdUdmOspMr3YkLm; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Cullen Jennings , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava wrote: > Hi Jonathan, > > Well, for the tool itself to work, we need to have the proposed > extensions. Not true. See below. > Only looking into the log info is not sufficient? When one > should look and from which proxies etc in the real life deployment > scenarios is difficult. I don't think so. One solution is to do a daily log analysis across all of the proxies in a domain, and see if any of them said they used a ciphersuite that the domain declares unacceptable. Similarly, every day or so you could read the configs across all proxies in the domain and check the configured ciphersuites. These kinds of config audit tools are commonplace. > > How can we differentiate 3DES (from the old ones), AES128 (3261), and > AES256 another new cipher-suite? They have different levels. They need > to be exposed irrespective of configuration errors etc. I don't understand what you are saying. The proxy would log and/or be configured with a specific ciphersuite. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 15:33:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXJC-00009e-Cu; Tue, 08 Aug 2006 15:32:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXJB-00009Z-1K for sip@ietf.org; Tue, 08 Aug 2006 15:32:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAXJ8-0008WD-Lc for sip@ietf.org; Tue, 08 Aug 2006 15:32:09 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 08 Aug 2006 12:32:06 -0700 X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="310458886:sNHT27934548" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78JW5P1013686; Tue, 8 Aug 2006 12:32:05 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k78JW4uJ000160; Tue, 8 Aug 2006 12:32:05 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 15:32:04 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 15:32:04 -0400 Message-ID: <44D8E6B2.3040604@cisco.com> Date: Tue, 08 Aug 2006 15:32:02 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-gruu-10.txt References: <1ECE0EB50388174790F9694F77522CCF0BFA2E24@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0BFA2E24@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2006 19:32:04.0483 (UTC) FILETIME=[54090530:01C6BB21] DKIM-Signature: a=rsa-sha1; q=dns; l=2504; t=1155065525; x=1155929525; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-gruu-10.txt; X=v=3Dcisco.com=3B=20h=3DOe63TwOBTy3cXgn13P+7nMbO/co=3D; b=SSpu8GsaUObQJxhcmhKu7z4KJ6pkjDqEwjb2GaZPOswsq+zTP3rF9D5D1I9IpFjHbRw2p7qC pZ8MsphgZQrMeGAnSXjlfQN8gN5vdIj04wDBONhR0ptzfoUsRjY8YCZQ; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Francois Audet wrote: > Hi Jonathan, > > I'm having some problem reconciling parts of gruu-10 with RFC 3261. > > (This problem is not gruu-specific, it also applies to the sips > guidelines > draft). > > In section 7.1.2 of gruu-10: > > A registrar MUST create both the SIP and SIPS versions of the GRUU, > such that if the GRUU exists, both URI exist. > > ...and later in 7.1.2.1 of gruu-10: > > If the To > header field in the REGISTER request contains a SIP URI, the SIP > version of the GRUU is returned. If the To header field in the > REGISTER request contains a SIPS URI, the SIPS version of the GRUU is > returned. > > > However, in RFC 3261/19.14: > > Some operations in this specification require determining whether two > SIP or SIPS URIs are equivalent. In this specification, registrars > need to compare bindings in Contact URIs in REGISTER requests (see > Section 10.3.). SIP and SIPS URIs are compared for equality > according to the following rules: > > o A SIP and SIPS URI are never equivalent. > > > It's not clear to me what this all means... > > Are we saying that when we register, it really doesn't matter if the > AOR, > and Contact (and GRUU) are SIP or SIP because both will end up being > "created"? It is true that SIP and SIPS URI are never equivalent based on URI comparison, but they always point to the same resource, and if one of them exists in a domain, so too does the other. > > The distinction between the two in registration would therefore be > purely mechanical (i.e., if AOR is SIP, Contact/GRUU is SIP, and if > AOR is SIPS, Contact/GRUU is SIPs)? GRUU is discussing the mechanical aspect. Its trying to skirt the bigger issue of what it means to register a SIPS AOR in the To, vs. a SIP AOR. It just says what happens with GRUU processing depending on which you do. Indeed, we could decide later on to disallow a SIPS URI in a To header field of a REGISTER, and the GRUU spec remains valid. I'm really hoping to not have to figure out the whole sips mess to progress GRUU. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 15:52:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXag-0002tP-2c; Tue, 08 Aug 2006 15:50:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXaU-0002XV-Nd; Tue, 08 Aug 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAXaU-0001vF-Bv; Tue, 08 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 454AB26E32; Tue, 8 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAXaU-0005dv-4O; Tue, 08 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 08 Aug 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Connected Identity in the Session Initiation Protocol (SIP) Author(s) : J. Elwell Filename : draft-ietf-sip-connected-identity-01.txt Pages : 24 Date : 2006-8-8 Because of retargeting of a Session Initiation Protocol (SIP) dialog- forming request, the User Agent Server (UAS) can have a different identity from that in the To header field. This document provides a means for that User Agent (UA) to supply its identity to the peer UA by means of a request in the reverse direction and for that identity to be signed by an Authentication Service. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in a Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). This work is being discussed on the sip@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-identity-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-connected-identity-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-connected-identity-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-8131903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connected-identity-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connected-identity-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-8131903.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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-- From sip-bounces@ietf.org Tue Aug 08 16:21:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAY3U-0006I4-QX; Tue, 08 Aug 2006 16:20:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAY3T-0006Gg-I8 for sip@ietf.org; Tue, 08 Aug 2006 16:19:59 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAY3S-0004TQ-2k for sip@ietf.org; Tue, 08 Aug 2006 16:19:59 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J3P00E014HT2W@siemenscomms.co.uk> for sip@ietf.org; Tue, 08 Aug 2006 21:20:17 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J3P00C604HTR1@siemenscomms.co.uk> for sip@ietf.org; Tue, 08 Aug 2006 21:20:17 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 08 Aug 2006 21:19:56 +0100 Content-return: allowed Date: Tue, 08 Aug 2006 21:19:55 +0100 From: "Elwell, John" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-01.txt To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670993306F@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Changes from the 00 draft are mainly based on consensus at the Montreal meeting on open issues and a general tidy-up to make it compliant with RFC 4485. Particular changes: - some terms defined and used consistently; - fixed on the UPDATE method for the additional request; - mandating that an UPDATE request be sent even if identity has not changed compared with that in To header field (to give the opportunity to have it signed); - note on what authentication service does if identity in From header field is not one it is allowed to assert; - additional explanation in some places; - proper population of messages in examples; - limiting of second example to transfer by a B2BUA rather than trying to be too general. The only thing missing is the content of the Identity header fields - these will need to be calculated when we have finished making changes to the message contents. I believe the document should be ready for the review process. John > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 08 August 2006 20:50 > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-01.txt > > 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 : Connected Identity in the Session > Initiation Protocol (SIP) > Author(s) : J. Elwell > Filename : draft-ietf-sip-connected-identity-01.txt > Pages : 24 > Date : 2006-8-8 > > Because of retargeting of a Session Initiation Protocol (SIP) dialog- > forming request, the User Agent Server (UAS) can have a different > identity from that in the To header field. This document provides a > means for that User Agent (UA) to supply its identity to the peer UA > by means of a request in the reverse direction and for that identity > to be signed by an Authentication Service. The same mechanism can be > used to indicate a change of identity during a dialog, e.g., because > of some action in a Public Switched Telephone Network (PSTN) behind a > gateway. This document normatively updates RFC 3261 (SIP). > This work is being discussed on the sip@ietf.org mailing list. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > dentity-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-connected-identity-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-sip-connected-identity-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 16:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAYVF-0007Gk-En; Tue, 08 Aug 2006 16:48:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAYVD-0007GO-3s for sip@ietf.org; Tue, 08 Aug 2006 16:48:40 -0400 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAYVA-0005fH-Sg for sip@ietf.org; Tue, 08 Aug 2006 16:48:39 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20060808204835b1100nt4mbe>; Tue, 8 Aug 2006 20:48:36 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k78KmYeY003491 for ; Tue, 8 Aug 2006 16:48:34 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k78KmY2v003487; Tue, 8 Aug 2006 16:48:34 -0400 Date: Tue, 8 Aug 2006 16:48:34 -0400 Message-Id: <200608082048.k78KmY2v003487@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <62B9B0847CC47543B6B3B5E26BD268E60DB33BE2@zrc2hxm2.corp.nortel.com> (samirsr@nortel.com) Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DB33BE2@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Samir Srivastava" My only requirement is, I should get the PSTN kind of security in VoIP. In PSTN, I don't have to worry about the call pattern tracking etc by anybody tapping on the wire. Generally, because people don't bother. As far as I know, the data on the wire is not protected particularly well. In practice, it's usually cheaper to tap the targeted user's access line, or to suborn a person in the organization, than go to the trouble of physically tapping a high-capacity PSTN line. And people believe that the US National Security Agency taps and analyzes essentially all international communications. People who use the PSTN for seriously sensitive purposes (banks, military, diplomats) use end-to-end security. I can talk my SSN, bank a/c etc without any fear. You can use SSL to communicate with your bank's server as well. These proposals only make hop-by-hop security more robust against a particular class of problems -- a proxy using a less-secure cipher than the user would want, allowing an adversary to tap the line. But if we are worrying about trusting proxies, the biggest risk is subornation of the proxy itself, INHO. I think effort would better be spend in adding effective end-to-end security than trying to remove one of the many weaknesses of the hop-by-hop scheme. Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 16:52:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAYXM-00004u-Pv; Tue, 08 Aug 2006 16:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAYXM-0008WR-60 for sip@ietf.org; Tue, 08 Aug 2006 16:50:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAXoW-0003Um-Tp for sip@ietf.org; Tue, 08 Aug 2006 16:04:32 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAXn4-0003sg-3v for sip@ietf.org; Tue, 08 Aug 2006 16:03:03 -0400 Received: from [64.101.149.124] (mikwils2-w2k.cisco.com [64.101.149.124]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k78K55qS025179 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 8 Aug 2006 15:05:06 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Tue, 8 Aug 2006 15:02:50 -0500 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.6 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 8, 2006, at 9:38 AM, Rohan Mahy wrote: > > The specific proposal works like this. A UAC which has an outbound > URI indicating with ;keepalive=stun that the next hop can support > STUN messages on the SIP port, needs to verify the first hop > supports STUN before sending any STUN messages. The UAC sends its > first SIP message to the next hop with a Proxy-Require: sip-stun. > If the URI was correct (STUN was supported), and the first-hop is > an intermediary, the first-hop removes the Proxy-Require and > forwards the SIP request (probably a REGISTER request) along adding > no additional delay. A positive response to a REGISTER or OPTIONS > with Supported: outbound and no error counts as positive > confirmation that either the registrar supports STUN or expects to > never receive a request without getting it from an outbound proxy > which did not complain about the Proxy-Require [1]. If the UAC was > misconfigured (the first-hop intermediary does not support STUN > keepalives), either the first hop will reject the SIP request (if > it is an intermediary), or the registrar will not include an > indicator that it supports outbound (if the first hop was the > registrar). > Cullen suggested an alternate possibility that might work. I'll try and paraphrase: A UAC which has an outbound URI indicating with ;keepalive=stun that the next hop can support STUN messages on the SIP port needs to verify the first hop supports STUN before repeatedly sending STUN messages. The UAC may initially try sending STUN messages to the SIP port of the first hop node. If the UAC does not receive a correct STUN response (within some timer?) then it must assume that this mode does not support STUN, and proceed without using STUN until it has some evidence that the first-hop node might have changed, in which case it retries the STUN requests as per the initial attempt. I think it's probably okay to stun a server a few times before deciding it doesn't like being stunned -- after all, the primary risk is one of slowing down service for the user doing the stunning, not shutting down the server being stunned. What I object to is a specification that says you go on stunning it indefinitely, perhaps millions of times over the course of an association, with no way to discover that you really shouldn't be stunning it. Set phasers on "stun", Mr. Sulu! -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 18:06:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAZh4-0000tW-Te; Tue, 08 Aug 2006 18:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAZh4-0000sc-BE for sip@ietf.org; Tue, 08 Aug 2006 18:04:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAZh4-00068e-7w for sip@ietf.org; Tue, 08 Aug 2006 18:04:58 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAZgx-000612-Sn for sip@ietf.org; Tue, 08 Aug 2006 18:04:58 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k78M4kMc021663; Tue, 8 Aug 2006 17:04:46 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k78M4jN20010; Tue, 8 Aug 2006 17:04:45 -0500 (CDT) Message-ID: <44D90A7D.1030303@lucent.com> Date: Tue, 08 Aug 2006 17:04:45 -0500 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] comments on draft-ietf-sip-connect-reuse-05 References: <44ADE168.7050309@cisco.com> <44AF59A8.1000304@lucent.com> <77482B40-90DF-43A7-BC76-07EA1AF05C52@cisco.com> In-Reply-To: <77482B40-90DF-43A7-BC76-07EA1AF05C52@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > Big question ... [...] > I don't think this works from some TLS situations. If a proxy is > hosting two virtual domain red and blue both with TLS and use the > same port for both using the extended hellos TLS options. Cullen: Thanks for being persistent on this one. This situation was listed as an open issue at the Dallas IETF presentation (see http://www3.ietf.org/proceedings/06mar/slides/sip-6.pdf). So, I think we can solve this with some work. More inline; I will preserve the description of the problem you provided for context. > Now both the red and blue domains have a user called tel:1234 but we > don't want red tel:1234 to get IMs meant for blue. Blue sends an IM > to Alice at some other domain. This forms an alias to the server. > Now Red bob sends an IM to Alice - this updates the alias and > basically hijacks blue. When ALice relies to blue, the proxy in > Alice's domain will mistakenly select the TLS connection that was > formed by red domain since it goes to the correct ip address, port, > and transport. The virtual domain that servers red and blue will > process the request in the context of red since it received it over > a TLS connection that is part of the red domain. You might say this > is a corner case but hosting multiple virtual domains this way is > very desirable and the HTTP people have been working hard to make > this easier to deploy. The latest version of common TLS libraries > are starting to support this and I expect to see more servers that > can do this. (PS. I think I have mentioned this on several different > versions of this document - let me know if I am not making any > sense) In order to arrive at how to solve this, the idea from Jonathan's email about a server caching client certificates for later use come into the picture. Here are the steps: 1) We have a proxy P that has two virtual domains -- red.com and blue.com -- accessible at port 5061 (note that in the scenario we are talking about, the destination port really does not matter. The problem arises when P sends *out* requests from its respective domains to a third party, and that third party wants to re-use the ensuing connection for requests in the backwards direction). 1a) P has a physical address of 192.168.1.2. 2) red.com has a user with a URI of sip:bob@red.com. 3) blue.com has a user with a URI of sip:bob@blue.com. 4) Now, bob@blue.com sends out a request to Alice through P: MESSAGE sips:alice@P2.com SIP/2.0 From: ;tag=8uxy--y6 Via: SIP/2.0/TLS blue.com;branch=... ... 5) Alice's proxy (P2) gets the request and creates an alias: Dest. Dest. Dest. Dest. Alias Address Port Transport Certificate Descriptor 192.168.1.2 5061 TLS blue.com 28 Note the new column (Dest. Certificate) -- this is key to solving this particular problem. The certificate from blue.com is cached by P2, and the domain name in the column is got from either the Via, or better yet, from the SAN in the certificate. Now requests from P2 towards the blue.com:5061 domain will go through the alias descriptor 28, which is tied to 192.168.1.2:6666 (port 6666 being the source port chosen by the sending TCP). 6) At some later time, bob@red.com sends a request to Alice through P: MESSAGE sips:alice@P2.com SIP/2.0 From: ;tag=9j7-y6 Via: SIP/2.0/TLS red.com;branch=... ... 7) Alice's proxy (P2) gets the request and updates its alias table with a new row: Dest. Dest. Dest. Dest. Alias Address Port Transport Certificate Descriptor 192.168.1.2 5061 TLS blue.com 28 192.168.1.2 5061 TLS red.com 32 Requests from P2 towards the red.com:5061 domain will go through the alias descriptor 32, which is tied to 192.168.1.2:7777 (port 7777 being the source port chosen by the sending TCP). 8) When P2 wants to send a request in the opposite direction, it will run the next hop URI through rfc3263 resolution. That resolution will result in an IP address/port/transport (192.168.1.2:5061:TLS). But instead of simply sending it to the first such row from the alias table, P2 will need to authenticate the URI used in the rfc3263 resolution to the appropriate certificate in order to choose the right descriptor. Thus, P knows that all requests coming in the backwards direction over 192.168.1.2:6666 belong to blue.com and those arriving over 192.168.1.2:7777 belong to red.com. I know this makes for a rather complex set of gyrations, but if we want to support name-based virtual servers, then this is one way that accounts for the requirements listed in Section 6 of the connect-reuse draft. If there are better and more elegant ways to do this, I would love to hear them. Thoughts? Thanks. - vijay _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 18:08:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAZiu-0001uj-L0; Tue, 08 Aug 2006 18:06:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAZit-0001oV-1W for sip@ietf.org; Tue, 08 Aug 2006 18:06:51 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAZir-0006Ll-L6 for sip@ietf.org; Tue, 08 Aug 2006 18:06:51 -0400 Received: (qmail 5671 invoked by uid 0); 8 Aug 2006 22:06:47 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Aug 2006 22:06:47 -0000 Message-ID: <001201c6bb36$f04e4fd0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dean Willis" , "Rohan Mahy" References: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 00:06:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, see inline Regards, Jeroen > > On Aug 8, 2006, at 9:38 AM, Rohan Mahy wrote: > >> >> The specific proposal works like this. A UAC which has an outbound URI >> indicating with ;keepalive=stun that the next hop can support STUN >> messages on the SIP port, needs to verify the first hop supports STUN >> before sending any STUN messages. The UAC sends its first SIP message to >> the next hop with a Proxy-Require: sip-stun. If the URI was correct >> (STUN was supported), and the first-hop is an intermediary, the >> first-hop removes the Proxy-Require and forwards the SIP request >> (probably a REGISTER request) along adding no additional delay. A >> positive response to a REGISTER or OPTIONS with Supported: outbound and >> no error counts as positive confirmation that either the registrar >> supports STUN or expects to never receive a request without getting it >> from an outbound proxy which did not complain about the Proxy-Require >> [1]. If the UAC was misconfigured (the first-hop intermediary does not >> support STUN keepalives), either the first hop will reject the SIP >> request (if it is an intermediary), or the registrar will not include an >> indicator that it supports outbound (if the first hop was the >> registrar). >> > > Cullen suggested an alternate possibility that might work. > Are you suggesting an alternative because there is something wrong with the proposal from Rohan above? For outbound purposes, the UAC won't have a need to send a STUN request until it has established a flow (ie upon 200 OK to REGISTER), and then only after the interval timer expires (I believe it was something like 24 secs minimum for UDP, more for TCP) Perhaps the case is different for non-outbound STUNning, but if the REGISTER OK provides information to determine support, I don't see a need to poke the proxy. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 18:55:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAaS1-00006w-88; Tue, 08 Aug 2006 18:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAaRz-0008Vn-Kc for sip@ietf.org; Tue, 08 Aug 2006 18:53:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAYpX-0007di-KI for sip@ietf.org; Tue, 08 Aug 2006 17:09:39 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAYVm-0004zP-CO for sip@ietf.org; Tue, 08 Aug 2006 16:49:16 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k78KnB0v029314 for ; Tue, 8 Aug 2006 23:49:11 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 23:49:11 +0300 Received: from essapo-nirac253225.europe.nokia.com ([10.162.253.225]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Aug 2006 23:49:10 +0300 From: Aki Niemi To: sip Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Tue, 08 Aug 2006 23:49:09 +0300 Message-Id: <1155070150.14419.18.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2006 20:49:10.0467 (UTC) FILETIME=[19562930:01C6BB2C] X-Spam-Score: -2.5 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] Question regarding instance ID in GRUU and outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Howdy, I read GRUU and outbound, and an old nagging concern of mine resurfaced: what the heck do we need the instance ID for? Seems outbound uses it to guarantee uniqueness of flows in a registrar, but to me it sounds weird that the task of acquiring unique IDs within the registrar's internal state is left to the UA -- after all, browsers don't generally generate cookies themselves but store whatever the website gives them. To me, a much better approach would be to have the registrar generate and allocate a unique ID (perhaps the 'opaque' used in GRUU?) for the first REGISTER, and whenever a client registers with that ID again, it is deemed the same UA. A REGISTER without an ID would be another UA instance. Even DHCP clients' leases seem to survive reboots without some weird URN generation, so I don't think that it's unreasonable to require UAs to store their outbound IDs either. I mean, they already have to store the reg-id, no? (Not to mention web cookies...) And worst case is you need to garbage-collect some stale flows, in case a UA happens to forget its ID, but that you need to be doing in any case. We chose a similar approach over instance ID in PUBLISH, which uses etags generated by the server to identify uniqueness of publisher instances. With PUBLISH, UAs are also instructed to remember their etags, even across reboots. Cheers, Aki _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 18:57:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAaTl-0000y7-Hm; Tue, 08 Aug 2006 18:55:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAaTk-0000y2-CM for sip@ietf.org; Tue, 08 Aug 2006 18:55:16 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAaTi-00064Z-F5 for sip@ietf.org; Tue, 08 Aug 2006 18:55:15 -0400 Received: from BPenfield [10.0.200.6] by acmepacket.com with ESMTP (SMTPD-9.03) id A6550620; Tue, 08 Aug 2006 18:55:17 -0400 Message-ID: <012f01c6bb3d$b07785a0$800101df@acmepacket.com> From: "Bob Penfield" To: "Dean Willis" , "Rohan Mahy" References: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Tue, 8 Aug 2006 18:55:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Setting phaser to "kill" ;) Seriously, If the first thing a non-STUN-supporting proxy sees for a new connection is a STUN message, It may see it as an attack and tear down the connection and possibly black-list the UA. IMO, the requirement is that the UA be able to verify that the proxy supports STUN before it sends a STUN packet. I am happy with Rohan's proposal. Now, if I were implementing a UA, I would certainly have it stop STUNing if it never saw a STUN response. Maybe the draft should say such to handle the case where a UA ends up connecting directly to a non-STUN-supporting registrar that thinks it has outbound proxies to handle the STUNing. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Dean Willis" To: "Rohan Mahy" Cc: "IETF SIP List" Sent: Tuesday, August 08, 2006 4:02 PM Subject: Re: [Sip] Outbound Issues: slides 3 and 4 > > On Aug 8, 2006, at 9:38 AM, Rohan Mahy wrote: > >> >> The specific proposal works like this. A UAC which has an outbound URI >> indicating with ;keepalive=stun that the next hop can support STUN >> messages on the SIP port, needs to verify the first hop supports STUN >> before sending any STUN messages. The UAC sends its first SIP message to >> the next hop with a Proxy-Require: sip-stun. If the URI was correct >> (STUN was supported), and the first-hop is an intermediary, the >> first-hop removes the Proxy-Require and forwards the SIP request >> (probably a REGISTER request) along adding no additional delay. A >> positive response to a REGISTER or OPTIONS with Supported: outbound and >> no error counts as positive confirmation that either the registrar >> supports STUN or expects to never receive a request without getting it >> from an outbound proxy which did not complain about the Proxy-Require >> [1]. If the UAC was misconfigured (the first-hop intermediary does not >> support STUN keepalives), either the first hop will reject the SIP >> request (if it is an intermediary), or the registrar will not include an >> indicator that it supports outbound (if the first hop was the >> registrar). >> > > Cullen suggested an alternate possibility that might work. > > I'll try and paraphrase: > > A UAC which has an outbound URI indicating with ;keepalive=stun that the > next hop can support STUN messages on the SIP port needs to verify the > first hop supports STUN before repeatedly sending STUN messages. The UAC > may initially try sending STUN messages to the SIP port of the first hop > node. If the UAC does not receive a correct STUN response (within some > timer?) then it must assume that this mode does not support STUN, and > proceed without using STUN until it has some evidence that the first-hop > node might have changed, in which case it retries the STUN requests as > per the initial attempt. > > I think it's probably okay to stun a server a few times before deciding > it doesn't like being stunned -- after all, the primary risk is one of > slowing down service for the user doing the stunning, not shutting down > the server being stunned. What I object to is a specification that says > you go on stunning it indefinitely, perhaps millions of times over the > course of an association, with no way to discover that you really > shouldn't be stunning it. > > Set phasers on "stun", Mr. Sulu! > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 08 19:32:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAb2O-000184-Rb; Tue, 08 Aug 2006 19:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAb2O-00017z-08 for sip@ietf.org; Tue, 08 Aug 2006 19:31:04 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAb2M-0005eo-MW for sip@ietf.org; Tue, 08 Aug 2006 19:31:03 -0400 Received: from [64.101.149.220] (deawilli-t42ciscocom.cisco.com [64.101.149.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k78NXBj2025967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Aug 2006 18:33:13 -0500 Message-ID: <44D91E3C.6020204@softarmor.com> Date: Tue, 08 Aug 2006 18:29:00 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> In-Reply-To: <1155070150.14419.18.camel@macbuster.research.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki Niemi wrote: > Howdy, > > I read GRUU and outbound, and an old nagging concern of mine resurfaced: > what the heck do we need the instance ID for? > > Seems outbound uses it to guarantee uniqueness of flows in a registrar, > but to me it sounds weird that the task of acquiring unique IDs within > the registrar's internal state is left to the UA -- after all, browsers > don't generally generate cookies themselves but store whatever the > website gives them. Well, to answer your nagging or "persistent" question, I believe the instance ID is there to create persistence. The idea (to which I'm not sure I subscribe) is that a GRUU is a very long-lived thing. For example, if client X registers with domain example.com in 2004, and then again in 2011, domain example.com should assign the exact same GRUU on both occasions. The only way we could come up with to do this (that didn't require eternal state in the registrar) was to make the assigned GRUU dependent on a transformation of "something unique to the client". > To me, a much better approach would be to have the registrar generate > and allocate a unique ID (perhaps the 'opaque' used in GRUU?) for the > first REGISTER, and whenever a client registers with that ID again, it > is deemed the same UA. A REGISTER without an ID would be another UA > instance. I think that works, but it doesn't have this long-lived persistence property that some people find desirable. So the argument, should we decide to revisit it, is "Do GRUUs need to be effectively immortal, or is okay if they're ephemeral?" So far, we seem to have a consensus (recorded many times in meetings and on the list) that we subscribe to the immortality model. Unless somebody has some real motivation otherwise, I suggest it might be better not to open that particular can of fish bait. -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 19:36:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAb5T-0001n4-Nx; Tue, 08 Aug 2006 19:34:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAb5S-0001mu-HH for sip@ietf.org; Tue, 08 Aug 2006 19:34:14 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAb5R-00064c-7U for sip@ietf.org; Tue, 08 Aug 2006 19:34:14 -0400 Received: from [64.101.149.220] (deawilli-t42ciscocom.cisco.com [64.101.149.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k78NaIgl025978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Aug 2006 18:36:19 -0500 Message-ID: <44D91EF7.8020102@softarmor.com> Date: Tue, 08 Aug 2006 18:32:07 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Outbound Issues: slides 3 and 4 References: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> <001201c6bb36$f04e4fd0$31713b51@BEMBUSTER> In-Reply-To: <001201c6bb36$f04e4fd0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Are you suggesting an alternative because there is something wrong with > the proposal from Rohan above? The only thing I have seen in Rohan's proposal that makes people queazy is the handling of the proxy-require -- that is, removing it in the first hop proxy. To quote a few IETF's back, "That doesn't bother me at all". But it seems to bother Cullen and a few others, even if I did borrow his words to say I'm ok with it. -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 20:17:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAbjO-0007dC-KD; Tue, 08 Aug 2006 20:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAbjO-0007d7-0R for sip@ietf.org; Tue, 08 Aug 2006 20:15:30 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAbjM-00018k-Ir for sip@ietf.org; Tue, 08 Aug 2006 20:15:29 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k790FOI13924; Tue, 8 Aug 2006 20:15:24 -0400 (EDT) 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 Subject: RE: [Sip] Continuation of WGLC on draft-ietf-sip-gruu-10 Date: Tue, 8 Aug 2006 19:11:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF06F68BF6@zrc2hxm0.corp.nortel.com> In-Reply-To: <5D1A7985295922448D5550C94DE291801E50FD@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Continuation of WGLC on draft-ietf-sip-gruu-10 thread-index: Aca4t6jzb0cIdg3jQp2xn/3iF5Fd1gBtQqgQ From: "Francois Audet" To: "Drage, Keith \(Keith\)" , "IETF SIP List" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've got a Minor Editorial comment In section 12, I would like to see the content of messages 3 and 4. In particular, I'd like to see what the Request-URI for those two messages would look like. For example, I'm assuming that Message 4's Request-URI would be as Message 9's=20 Request-URI? > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: Saturday, August 05, 2006 1:31 PM > To: IETF SIP List > Subject: [Sip] Continuation of WGLC on draft-ietf-sip-gruu-10 >=20 > Working Group Last Call > ----------------------- >=20 > Jonathan has just published > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-10.txt > which should take into account all the major comments that=20 > have been so far received on this document. >=20 > Having initiated WGLC on this document on 13th January 2004,=20 > and revised that WGLC on 5th July 2004 and 26th October 2005=20 > we would really like to reach a final conclusion of this WGLC.=20 >=20 > Therefore please review the document and submit your WGLC=20 > comments within two weeks, ie. By the 21st August 2006. >=20 > Process > ------- >=20 > In addition to an open invitation for review by all members=20 > of the working group, we will be soliciting full review by a=20 > number of experts who we believe will provide a good and=20 > complete understanding of the issues and problems, if any,=20 > with the document. If you consider you should be part of this=20 > list this please contact the WG chairs. >=20 > The WG chairs will compile all submitted comments into a=20 > single review document which will be discussed on the=20 > conference call below. Please therefore submit your comments=20 > (to the SIP WG list and the WG chairs) with information under=20 > the following headings for each comment: >=20 > - location in document > - nature of comment (editorial, minor technical, critical error, > absolute show stopper - use your judgement on this) > - comment > - proposed fix >=20 > We intend to have a conference call for reviewers to conclude=20 > on the quality of the document on Monday 4th September at: >=20 > 8:00 am Pacific Time > 10:00 am Central US Time > 11:00 am Eastern US Time > 4:00 pm UK > 5:00 pm Central European Summer Time >=20 > Bridge details as follows: >=20 > Access Phone Number: 8007718734 > International Access Phone Number: +1 6477233953 7-Digit=20 > Access Code: 5776249=20 >=20 > While this call is open to all WG members, we would expect=20 > only people who have reviewed the document on this conference=20 > call. For details of the process please see previous=20 > communication. Note that the above does include those=20 > reviewers who reviewed the document and had no comments - if=20 > you are in this class, please report it. >=20 > Regards >=20 > Keith >=20 > Keith Drage > drage@lucent.com > tel: +44 1793 776249 >=20 > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 20:31:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAbxV-0008EJ-EV; Tue, 08 Aug 2006 20:30:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAbxT-0008EA-Nd for sip@ietf.org; Tue, 08 Aug 2006 20:30:03 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAbxR-00028v-DK for sip@ietf.org; Tue, 08 Aug 2006 20:30:03 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k790Tul15070; Tue, 8 Aug 2006 20:29:56 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 8 Aug 2006 19:29:55 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DB9B326@zrc2hxm2.corp.nortel.com> In-Reply-To: <44D8E4E7.9060801@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: Aca7IEzfGyzplKG1SBeOKovi1ckDrQAKk1Uw From: "Samir Srivastava" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Cullen Jennings , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, Thx for your comments. Responses in-line below. Thx Samir >=20 > I don't think so. One solution is to do a daily log analysis across=20 > all of the proxies in a domain, and see if any of them said they used=20 > a ciphersuite that the domain declares unacceptable. Similarly, every=20 > day or so you could read the configs across all proxies in the domain=20 > and check the configured ciphersuites. These kinds of config audit=20 > tools are commonplace. >=20 Now your tool has changed from the call trace to log file analysis. Here periodicity of checks will decide the time window where channel is left less secure. This insecurity is related on the wire (Not like misrouting etc),so we need to be very much careful. > > > > How can we differentiate 3DES (from the old ones), AES128 (3261),=20 > > and > > AES256 another new cipher-suite? They have different levels. They=20 > > need to be exposed irrespective of configuration errors etc. >=20 > I don't understand what you are saying. The proxy would log and/or be=20 > configured with a specific ciphersuite. >=20 I intend to state that secure protocol versions, cipher-suites will be varying in time. Now If I want to complete a request with AES256 cipher-suite (Bank a/c etc use case) only, I cannot do it without specifying it explicitly. My home proxy provider being a best, is up-to-date with AES256 but where the call needs to be terminated, that path goes through other proxies which don't support AES256 but support older/current mandatory cipher-suite AES128 and 3DES. My home proxy or other proxies in between will downgrade it to AES128 or 3DES on the next hop, if AES256 is not stated explicitly. When I started looking into the cipher-suites, I was looking from the future proof point. I think, following will be good data points=20 1) How long it took to develop a cipher-suite, secure protocol etc 2) What was the computing power / technology /networking /parallelism etc available at that time 3) As the time passed, Resources in 2 become cheap, and attackers have more motivation to break the cipher-suites etc. 4) How long does it took to break the cipher-suites / secure protocols? =20 We can very easily see this being a variable in future too. TLS itself has two versions and another bis in progress. Security will be always N+1 stuff. Now think out-side of the current limited /islands of the deployment of SIP with the global equivalence of PSTN, It will be real difficult to find all SIP entities up-to-date on the fly. People who care about security, they will require it.=20 Thx Samir _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 20:34:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAbzo-0000Xh-TJ; Tue, 08 Aug 2006 20:32:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAbzn-0000Xc-2V for sip@ietf.org; Tue, 08 Aug 2006 20:32:27 -0400 Received: from mail2.alcanet.com.au ([203.62.196.17] helo=smtp-in.alcatel.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAbzl-0002Cr-6N for sip@ietf.org; Tue, 08 Aug 2006 20:32:27 -0400 Received: from nzmail01.alcatel.co.nz (localhost.localdomain [127.0.0.1]) by smtp-in.alcatel.com.au (8.12.8/8.12.8) with ESMTP id k790WInT025568 for ; Wed, 9 Aug 2006 10:32:19 +1000 From: Paul.Miller@alcatel.co.nz To: sip@ietf.org Message-ID: Date: Wed, 9 Aug 2006 12:33:26 +1200 X-MIMETrack: Serialize by Router on NZMAIL01/NZ/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/09/2006 12:33:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] Paul MILLER/NZ/ALCATEL is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I will be out of the office starting 09/08/2006 and will not return until 18/08/2006. I will respond to your message when I return. If you need me urgently I can be reached on my mobile by SMS, bear in mind this is ONLY for emergencies This email may contain privileged/confidential information. You may not copy or disclose this email to anyone without the written permission of the sender. If you have received this email in error please kindly delete this message and notify the sender. Opinions expressed in this email are those of the sender and not necessarily the opinions of the employer. This email and any attached files should be scanned to detect viruses. No liability will be accepted by the employer for loss or damage (whether caused by negligence or not) as a result of email transmission. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 20:41:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAc7F-0005sj-OW; Tue, 08 Aug 2006 20:40:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAc7E-0005se-Po for sip@ietf.org; Tue, 08 Aug 2006 20:40:08 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAc7D-0002iP-DU for sip@ietf.org; Tue, 08 Aug 2006 20:40:08 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 8067E1E8C1C; Tue, 8 Aug 2006 17:40:06 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DB9B326@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Tue, 08 Aug 2006 17:40:06 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DB9B326@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Tue, 8 Aug 2006 19:29:55 -0500") Message-ID: <86hd0mvj15.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Cullen Jennings , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP Reply-to: EKR X-Draft-From: ("nnmh:sip" 1334) References: <62B9B0847CC47543B6B3B5E26BD268E60DB9B326@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Gcc: nnmh+archive:sent --text follows this line-- "Samir Srivastava" writes: > I intend to state that secure protocol versions, cipher-suites will be > varying in time. Now If I want to complete a request with AES256 > cipher-suite (Bank a/c etc use case) only, I cannot do it without > specifying it explicitly. My home proxy provider being a best, is > up-to-date with AES256 but where the call needs to be terminated, that > path goes through other proxies which don't support AES256 but support > older/current mandatory cipher-suite AES128 and 3DES. My home proxy or > other proxies in between will downgrade it to AES128 or 3DES on the next > hop, if AES256 is not stated explicitly. So? You seem to be operating under the assumption that there's going to be some situation where some cipher suite is really broken and yet the proxies in the middle are still configured to only support it. I don't believe that to be the case. With regard to the particular examples you cite: AES-128 and 3DES are perfectly fine algorithms, well beyond the range of any conceivable brute force attack. So, you have to be imagining that some good analytic attack will be mounted in which case people will TURN OFF THAT ALGORITHM. And if you don't trust them to do so, then you shouldn't be trusting them to route your traffic, since you can't trust them to keep their software up to date and the vulnerability cycle for software is much shorter than the vulnerability cycle for cryptographic algorithms. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 21:50:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAdB4-0000EJ-7c; Tue, 08 Aug 2006 21:48:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAdB3-0000EE-F6 for sip@ietf.org; Tue, 08 Aug 2006 21:48:09 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAdB2-0005P1-4r for sip@ietf.org; Tue, 08 Aug 2006 21:48:09 -0400 Received: from [71.240.232.162] (helo=JMHLap3.stevecrocker.com) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GAdB0-0004X7-L5; Tue, 08 Aug 2006 21:48:07 -0400 Message-Id: <7.0.1.0.0.20060808214436.0403fdc0@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 08 Aug 2006 21:48:00 -0400 To: "Samir Srivastava" , "Jonathan Rosenberg" From: "Joel M. Halpern" Subject: RE: [Sip] Ciphersuites in SIP In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DB9B326@zrc2hxm2.corp.nor tel.com> References: <44D8E4E7.9060801@cisco.com> <62B9B0847CC47543B6B3B5E26BD268E60DB9B326@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120e26356c0b0470470468a54cc0e32133fae394aceeff94e20350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.240.232.162 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Cullen Jennings , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think my basic problem with this is that it still confuses the users concerns with the operators concerns. The user wants good security. He ought not want specific security mechanisms between proxies, but rather, he wants the proxies to do a good job. It is the operator's task to determine what the right mechanism (including crypto mechanism and crypto suite) to use at a given hop. To be really clear, I do not think the user has the right to say "proxies along the chain must not use IPSec, and must use TLS, and must use a specific cipher suite." The proxies don't belong to the end user. Heck, with the way things work in practice, the end user may not even know about the proxies. And very often neither end user has a contractual relationship with the intermediate proxies. Yours, Joel M. Halpern At 08:29 PM 8/8/2006, Samir Srivastava wrote: >Hi Jonathan, > Thx for your comments. Responses in-line below. >Thx >Samir > > > > > I don't think so. One solution is to do a daily log analysis across > > all of the proxies in a domain, and see if any of them said they used > > a ciphersuite that the domain declares unacceptable. Similarly, every > > day or so you could read the configs across all proxies in the domain > > and check the configured ciphersuites. These kinds of config audit > > tools are commonplace. > > > Now your tool has changed from the call trace to log file analysis. >Here periodicity of checks will decide the time window where channel is >left less secure. This insecurity is related on the wire (Not like >misrouting etc),so we need to be very much careful. > > > > > > > How can we differentiate 3DES (from the old ones), AES128 (3261), > > > and > > > AES256 another new cipher-suite? They have different levels. They > > > need to be exposed irrespective of configuration errors etc. > > > > I don't understand what you are saying. The proxy would log and/or be > > configured with a specific ciphersuite. > > >I intend to state that secure protocol versions, cipher-suites will be >varying in time. Now If I want to complete a request with AES256 >cipher-suite (Bank a/c etc use case) only, I cannot do it without >specifying it explicitly. My home proxy provider being a best, is >up-to-date with AES256 but where the call needs to be terminated, that >path goes through other proxies which don't support AES256 but support >older/current mandatory cipher-suite AES128 and 3DES. My home proxy or >other proxies in between will downgrade it to AES128 or 3DES on the next >hop, if AES256 is not stated explicitly. > >When I started looking into the cipher-suites, I was looking from the >future proof point. I think, following will be good data points > >1) How long it took to develop a cipher-suite, secure protocol etc >2) What was the computing power / technology /networking /parallelism >etc available at that time >3) As the time passed, Resources in 2 become cheap, and attackers have >more motivation to break the cipher-suites etc. >4) How long does it took to break the cipher-suites / secure protocols? > > We can very easily see this being a variable in future too. TLS itself >has two versions and another bis in progress. Security will be always >N+1 stuff. > > Now think out-side of the current limited /islands of the deployment >of SIP with the global equivalence of PSTN, It will be real difficult to >find all SIP entities up-to-date on the fly. People who care about >security, they will require it. > >Thx >Samir > >_______________________________________________ >Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 08 22:21:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAdfy-0001vh-Rf; Tue, 08 Aug 2006 22:20:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAdfx-0001vZ-Ng for sip@ietf.org; Tue, 08 Aug 2006 22:20:05 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAdfw-0003zg-Gz for sip@ietf.org; Tue, 08 Aug 2006 22:20:05 -0400 Received: from [71.240.232.162] (helo=JMHLap3.stevecrocker.com) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GAdft-0004TT-8h; Tue, 08 Aug 2006 22:20:01 -0400 Message-Id: <7.0.1.0.0.20060808221746.04065de8@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 08 Aug 2006 22:19:52 -0400 To: "Francois Audet" ,"Rohan Mahy" , "IETF SIP List" From: "Joel M. Halpern" Subject: RE: [Sip] Outbound Issues: slides 3 and 4 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0C184D04@zrc2hxm0.corp.nor tel.com> References: <1ECE0EB50388174790F9694F77522CCF0C184D04@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120e26356c0b0470470f3a80bd44f1530aa20dc23739b1d89a5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.240.232.162 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Personally, I read this as the ";keep-alive=stun" parameter appears in the list of outbound prixes. it needs to be a URI parameter because the contents of that list are URIs. There is no need for that parameter to actually appear in the request. Instead, proxy-require: sip-stun appears, and is removed by the first proxy after it determines that it understands and supports that. And if it supports it, then it will know to remove the line, so there is no hole where the proxy-require can leak. Yours, Joel At 02:46 PM 8/8/2006, Francois Audet wrote: >I'm also wondering if the ";keep-alive=stun" is still useful with the >addition of the Proxy-Require: sip-stun. It doesn't seem >to me that it is, except as an automatic configuration option for the >UAC. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 08 23:40:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAett-0004Oi-8o; Tue, 08 Aug 2006 23:38:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAetr-0004Oa-EN for sip@ietf.org; Tue, 08 Aug 2006 23:38:31 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAetq-0003dN-7Z for sip@ietf.org; Tue, 08 Aug 2006 23:38:31 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20060809033829b14005dbeke>; Wed, 9 Aug 2006 03:38:29 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k793cSeY012969 for ; Tue, 8 Aug 2006 23:38:28 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k793cSTC012965; Tue, 8 Aug 2006 23:38:28 -0400 Date: Tue, 8 Aug 2006 23:38:28 -0400 Message-Id: <200608090338.k793cSTC012965@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1155070150.14419.18.camel@macbuster.research.nokia.com> (aki.niemi@nokia.com) Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Aki Niemi Seems outbound uses it to guarantee uniqueness of flows in a registrar, but to me it sounds weird that the task of acquiring unique IDs within the registrar's internal state is left to the UA -- after all, browsers don't generally generate cookies themselves but store whatever the website gives them. I believe the presupposition is that the common case will be a physical "SIP telephone". It already must have a unique MAC address, and there is a simple, defined way to turn that into a URN. So it is assumed to be simpler for the device to generate an ID for itself from its MAC address than for it to get and remember the ID given to it by a registrar. Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 01:00:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAg8u-0005hW-7f; Wed, 09 Aug 2006 00:58:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAg8s-0005gu-Si for sip@ietf.org; Wed, 09 Aug 2006 00:58:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAg8s-0006Gp-QF for sip@ietf.org; Wed, 09 Aug 2006 00:58:06 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAg8q-0003iG-23 for sip@ietf.org; Wed, 09 Aug 2006 00:58:06 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k794vnF30224; Tue, 8 Aug 2006 21:57:49 -0700 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0C184D04@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0C184D04@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9b81dd8e911e238e815104ffa93c0091@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Tue, 8 Aug 2006 21:57:52 -0700 To: "Francois Audet" X-Mailer: Apple Mail (2.624) X-Spam-Score: -2.6 (--) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 8, 2006, at 11:46, Francois Audet wrote: > Rohan, > > I really like the idea of decoupling sip-stun support, versus > outbound support. > > But I'm findind the description quite complicated... > > I'm also wondering if the ";keep-alive=stun" is still useful with the > addition of the Proxy-Require: sip-stun. It doesn't seem > to me that it is, except as an automatic configuration option for the > UAC. > Since the UAC certainly requires much more configuration options (with > config-framework, or config files or whatever), I'm not sure it is > worth > the > effort. I don't see why this one in particular is more important than > any other. > > Let me try to paraphrase what you are saying, to make sure I understood > it properly: > > - "Proxy-require: sip-stun" means that the outbound proxy is required > to > support > sip-stun, i.e., the procedures of section 3.5. A consequence of this > is that > it precludes deployments where the sip-stun is supported not in the > first hop, > but later (e.g., the Registrar), but with some other intermedia > proxy > between. > > - "Supported: outbound" means that the Registrar supports the > procedures > of the > draft that are not related to sip-stun. > > - ";keep-alive=stun" is an indication for the UAC that stun-in-sip is > supported > by the network. Essentially an autoconfiguration option. yes > We have been using terms like "edge proxy", "outbound proxy" now "first > hop", > and "intermediary". > > To me, it seems that there are only two entities that are relevant > here: > > 1 - The outbound proxy. This is where all requests are sent, and the > entity that > terminates sip-in-stun. > > 2 - The Registrar. Also the entity that supports the "Outbound" > procedures (excluding > stun-in-sip). > > A very common scenario is where 1 & 2 are co-located. In this case the > Registrar is > the oubound-proxy and it does terminate sip-stun. > > Also, I don't understand why your point [1] is a problem. Wouldn't a > Registrar > that doesn't support stun-sip, but which is accesses directly (i.e., as > an outbound > proxy) just reject the REGISTER because it contained "Proxy-Require: > stun-sip" with > 420 with "Unsupported: stun-sip"? > > Are you worried that such a REGISTRAR may not believe the Proxy-Require > was intended for > itself? Exactly. Proxy-Require is generally supposed to be ignored by UAs. thanks, -rohan >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@ekabal.com] >> Sent: Tuesday, August 08, 2006 7:39 AM >> To: IETF SIP List >> Cc: Rohan Mahy >> Subject: [Sip] Outbound Issues: slides 3 and 4 >> >> >> We had a very long discussion in Montreal about discovery and >> validation of a SIP outbound proxy server's ability to >> receive STUN requests. While the vast majority of the room >> was comfortable that "keepalive=stun" in a URI was a >> sufficient indicator that an outbound proxy supports SIP and >> STUN over the same port, a small but extremely vocal minority >> had significant problems with this assumption. After a >> discussion with Dean, I am willing to try a validation >> proposal which adds no extra round trips if the SIP UA was >> indeed correctly configured. >> >> The specific proposal works like this. A UAC which has an >> outbound URI indicating with ;keepalive=stun that the next >> hop can support STUN messages on the SIP port, needs to >> verify the first hop supports STUN before sending any STUN >> messages. The UAC sends its first SIP message to the next hop >> with a Proxy-Require: sip-stun. If the URI was correct (STUN >> was supported), and the first-hop is an intermediary, the >> first-hop removes the Proxy-Require and forwards the SIP >> request (probably a REGISTER request) along adding no >> additional delay. A positive response to a REGISTER or >> OPTIONS with Supported: outbound and no error counts as >> positive confirmation that either the registrar supports STUN >> or expects to never receive a request without getting it from >> an outbound proxy which did not complain about the >> Proxy-Require [1]. If the UAC was misconfigured (the >> first-hop intermediary does not support STUN keepalives), >> either the first hop will reject the SIP request (if it is an >> intermediary), or the registrar will not include an indicator >> that it supports outbound (if the first hop was the registrar). >> >> Note that this proposal is not a full *discovery* mechanism, >> just a verification mechanism. For example, if the registrar >> doesn't support outbound, but the first-hop does, there is no >> way described here to discover that the first-hop can accept >> STUN keepalives. Do not confuse support of STUN with support >> of outbound. Supported: outbound implies that the registrar >> supports STUN or is configured to use an outbound proxy that >> does. The sip-stun option tag only means that you can send >> and receive STUN requests on your SIP port. While outbound >> requires STUN, STUN does not require outbound. >> >> [1] Also Note that there is a caveat that you can still shoot >> yourself in the foot if you allow messages to come straight >> to your registrar that does not support STUN. I think we >> agreed that we are not going to enumerate all the ways you >> can subtly break things in SIP though. >> >> thanks, >> -rohan >> >> >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 01:02:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAgBZ-0007dh-Pz; Wed, 09 Aug 2006 01:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAgBX-0007d6-Bp for sip@ietf.org; Wed, 09 Aug 2006 01:00:51 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAgBV-0006fE-V3 for sip@ietf.org; Wed, 09 Aug 2006 01:00:51 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k7950gF30246; Tue, 8 Aug 2006 22:00:42 -0700 In-Reply-To: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> References: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3616bad49af6bb4854de60203de332f7@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Tue, 8 Aug 2006 22:00:54 -0700 To: Dean Willis X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 8, 2006, at 13:02, Dean Willis wrote: > > On Aug 8, 2006, at 9:38 AM, Rohan Mahy wrote: > >> >> The specific proposal works like this. A UAC which has an outbound >> URI indicating with ;keepalive=stun that the next hop can support >> STUN messages on the SIP port, needs to verify the first hop supports >> STUN before sending any STUN messages. The UAC sends its first SIP >> message to the next hop with a Proxy-Require: sip-stun. If the URI >> was correct (STUN was supported), and the first-hop is an >> intermediary, the first-hop removes the Proxy-Require and forwards >> the SIP request (probably a REGISTER request) along adding no >> additional delay. A positive response to a REGISTER or OPTIONS with >> Supported: outbound and no error counts as positive confirmation that >> either the registrar supports STUN or expects to never receive a >> request without getting it from an outbound proxy which did not >> complain about the Proxy-Require [1]. If the UAC was misconfigured >> (the first-hop intermediary does not support STUN keepalives), either >> the first hop will reject the SIP request (if it is an intermediary), >> or the registrar will not include an indicator that it supports >> outbound (if the first hop was the registrar). >> > > Cullen suggested an alternate possibility that might work. > > I'll try and paraphrase: > > A UAC which has an outbound URI indicating with ;keepalive=stun that > the next hop can support STUN messages on the SIP port needs to verify > the first hop supports STUN before repeatedly sending STUN messages. > The UAC may initially try sending STUN messages to the SIP port of the > first hop node. If the UAC does not receive a correct STUN response > (within some timer?) then it must assume that this mode does not > support STUN, and proceed without using STUN until it has some > evidence that the first-hop node might have changed, in which case it > retries the STUN requests as per the initial attempt. I'm personally pretty happy with this, "if it ain't working, don't keep doing it approach." Could others comment if they like the approach or not? thanks, -rohan > I think it's probably okay to stun a server a few times before > deciding it doesn't like being stunned -- after all, the primary risk > is one of slowing down service for the user doing the stunning, not > shutting down the server being stunned. What I object to is a > specification that says you go on stunning it indefinitely, perhaps > millions of times over the course of an association, with no way to > discover that you really shouldn't be stunning it. > > Set phasers on "stun", Mr. Sulu! > > -- > Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 01:29:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAgbh-0004w6-TO; Wed, 09 Aug 2006 01:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAgbg-0004vy-RG for sip@ietf.org; Wed, 09 Aug 2006 01:27:52 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAgbf-0003wk-GO for sip@ietf.org; Wed, 09 Aug 2006 01:27:52 -0400 Received: from [192.168.2.104] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k795U0D4027153 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 9 Aug 2006 00:30:01 -0500 In-Reply-To: <7.0.1.0.0.20060808214436.0403fdc0@stevecrocker.com> References: <44D8E4E7.9060801@cisco.com> <62B9B0847CC47543B6B3B5E26BD268E60DB9B326@zrc2hxm2.corp.nortel.com> <7.0.1.0.0.20060808214436.0403fdc0@stevecrocker.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Ciphersuites in SIP Date: Wed, 9 Aug 2006 00:27:47 -0500 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Cullen Jennings , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 8, 2006, at 8:48 PM, Joel M. Halpern wrote: > I think my basic problem with this is that it still confuses the > users concerns with the operators concerns. > The user wants good security. He ought not want specific security > mechanisms between proxies, but rather, he wants the proxies to do > a good job. > It is the operator's task to determine what the right mechanism > (including crypto mechanism and crypto suite) to use at a given hop. > > To be really clear, I do not think the user has the right to say > "proxies along the chain must not use IPSec, and must use TLS, and > must use a specific cipher suite." The proxies don't belong to the > end user. Heck, with the way things work in practice, the end user > may not even know about the proxies. And very often neither end > user has a contractual relationship with the intermediate proxies. Worthy discussion points. Now, let's say the "user" here is a large enterprise who writes into a contract with their ITSP that they expect such-and-such a cipher to be used on their links. And we know that enterprise IT organizations have to meet specific standards (in the US, under Sarbanes-Oxley) for protection of financial data or customer-privacy data (big in Europe). Do they have the right to check up on whether their contract terms are being met?? What if the user is a government agency, who might be operating under a regulatory requirement? Have we seen regulatory requirements that make no sense before? Don't misunderstand -- I'm not saying that this is a high-priority issue, and we're probably spending more time dismissing it than it deserves. But somewhere in there I believe there are legitimate use- cases that are probably important to somebody. We just haven't described them adequately. Now, if somebody with either enough money to spend or an obvious use case wanted to step forward and claim the problem, perhaps our tune would change. For now, however, I think we have ample evidence that we do not have a consensus on the presentation of the problem or on the proposed solution, so I'd like to ask the participants to step back and take a breather. If further reflection brings a real substantive change in the problem statement (and I suspect that the "diagnostic" approach may bear fruit) I'd welcome a new draft discussing it. But the current discussion is not getting us anywhere that we need to be going right now. So please, step back and give it some thought before continuing. Thanks! -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 02:37:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAhf2-00084w-Pf; Wed, 09 Aug 2006 02:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAhf1-00084r-0X for sip@ietf.org; Wed, 09 Aug 2006 02:35:23 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAhez-0006J0-Ko for sip@ietf.org; Wed, 09 Aug 2006 02:35:22 -0400 Received: (qmail 9720 invoked by uid 0); 9 Aug 2006 06:35:19 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Aug 2006 06:35:19 -0000 Message-ID: <001801c6bb7d$fb41d6e0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" , "Francois Audet" References: <1ECE0EB50388174790F9694F77522CCF0C184D04@zrc2hxm0.corp.nortel.com> <9b81dd8e911e238e815104ffa93c0091@ekabal.com> Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 08:35:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> Are you worried that such a REGISTRAR may not believe the Proxy-Require >> was intended for >> itself? > > Exactly. Proxy-Require is generally supposed to be ignored by UAs. > Just a note: if the outbound draft defines the 'sip-stun' option tag, it should also discuss what it means to add 'Require: sip-stun', and what behavior is expected from the UAS in such a case In particular, I am thinking about non-outbound cases, where a UAC behind NAT wants to directly INVITE (or other dialog-creating request) another UA, without having a proxy in between. This is also relevant for the end-to-end security discussions (ie keeping the TLS connection alive) Regards, Jeroen _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 04:40:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAja7-0005qy-6G; Wed, 09 Aug 2006 04:38:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAja6-0005qt-1q for sip@ietf.org; Wed, 09 Aug 2006 04:38:26 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAja4-0003cn-Oz for sip@ietf.org; Wed, 09 Aug 2006 04:38:26 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 499437404E; Wed, 9 Aug 2006 10:38:23 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05062-01-43; Wed, 9 Aug 2006 10:38:22 +0200 (CEST) Received: from dhcp-wavelan-vo-32.publik.su.se (dhcp-wavelan-vo-32.publik.su.se [193.11.30.32]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 3CDD774014; Wed, 9 Aug 2006 10:38:18 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 10:36:43 +0200 User-Agent: KMail/1.9.3 References: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> <3616bad49af6bb4854de60203de332f7@ekabal.com> In-Reply-To: <3616bad49af6bb4854de60203de332f7@ekabal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608091036.43395.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.643 tagged_above=-99 required=7 tests=[AWL=0.022, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wednesday 09 August 2006 07:00, Rohan Mahy wrote: ... > I'm personally pretty happy with this, "if it ain't working, don't > keep doing it approach." > Could others comment if they like the approach or not? I am in favor of it, because ultimately there is no way to _know_ that the first hop actually handles STUN requests without sending one. The argument that a response containing something saying "I claim I can handle STUN requests you send me" is to be trusted, but configuration saying ";keepalive=stun" is not is flawed. The UA will still have to send a STUN request, and might or might not receive a response. It might be worth writing down that if you send a STUN request over a TCP session, and don't receive a response then you should tear down the TCP session and open a new one in case your peer's framing is messed up. On this new TCP session you should of course not send any STUN requests. I consider blacklisting an IP address that sends you one (1) packet you consider bad to be too aggressive. I wouldn't use a proxy that did that. /Fredrik _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 04:52:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAjla-00034J-Ul; Wed, 09 Aug 2006 04:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAjlZ-00034E-Gg for sip@ietf.org; Wed, 09 Aug 2006 04:50:17 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAjlZ-000516-0R for sip@ietf.org; Wed, 09 Aug 2006 04:50:17 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k797oFXH017940; Wed, 9 Aug 2006 10:50:16 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 11:50:13 +0300 Received: from esdhcp035153.research.nokia.com ([172.21.35.153]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Aug 2006 11:50:12 +0300 Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound From: Aki Niemi To: ext Dean Willis In-Reply-To: <44D91E3C.6020204@softarmor.com> References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44D91E3C.6020204@softarmor.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Wed, 09 Aug 2006 11:49:58 +0300 Message-Id: <1155113399.16458.27.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2006 08:50:12.0767 (UTC) FILETIME=[D3AD42F0:01C6BB90] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ti, 2006-08-08 kello 18:29 -0500, ext Dean Willis kirjoitti: > Aki Niemi wrote: > > Howdy, > > > > I read GRUU and outbound, and an old nagging concern of mine resurfaced: > > what the heck do we need the instance ID for? > > > > Seems outbound uses it to guarantee uniqueness of flows in a registrar, > > but to me it sounds weird that the task of acquiring unique IDs within > > the registrar's internal state is left to the UA -- after all, browsers > > don't generally generate cookies themselves but store whatever the > > website gives them. > > Well, to answer your nagging or "persistent" question, I believe the > instance ID is there to create persistence. > > The idea (to which I'm not sure I subscribe) is that a GRUU is a very > long-lived thing. For example, if client X registers with domain > example.com in 2004, and then again in 2011, domain example.com should > assign the exact same GRUU on both occasions. > > The only way we could come up with to do this (that didn't require > eternal state in the registrar) was to make the assigned GRUU dependent > on a transformation of "something unique to the client". Actually, this is completely orthogonal to the issue of who generates this "something". Similarly, I can make a website that never expires cookies. Persistence there doesn't require browsers issuing any kind of unique IDs; browsers simply need to store the cookies they receive and offer them to sites as necessary. > > To me, a much better approach would be to have the registrar generate > > and allocate a unique ID (perhaps the 'opaque' used in GRUU?) for the > > first REGISTER, and whenever a client registers with that ID again, it > > is deemed the same UA. A REGISTER without an ID would be another UA > > instance. > > I think that works, but it doesn't have this long-lived persistence > property that some people find desirable. > > So the argument, should we decide to revisit it, is "Do GRUUs need to be > effectively immortal, or is okay if they're ephemeral?" So far, we seem > to have a consensus (recorded many times in meetings and on the list) > that we subscribe to the immortality model. But sip-outbound doesn't even have this immortality model. The pattern in SIP outbound is that of web cookies. I think it's not good design to ignore that pattern and go with yet another approach that kind of does the same and might work, too. I see at least three problems with sip-outbound's use of the UUID URN: 1) It's generally a bad idea (and a security risk) to rely on the UA generating data to be used in registrar-internal state lookups. Even if the UUID seems all dandy and easy to use in database lookups, I'd still prefer to decide exactly with which data I populate my own database that holds my own internal state. 2) Generating a UUID is yet another obscure specification to read, interpret correctly and implement. I fear implementations won't get this right, and the registrar will simply have to make due with crappy instance IDs UAs are giving it. It has no other choice, even when those IDs are generated my malicious UAs that intentionally look for collisions. Cheers, Aki > Unless somebody has some real motivation otherwise, I suggest it might > be better not to open that particular can of fish bait. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.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 -- Aki Niemi Nokia Research Center _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 04:57:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAjqX-0006Jz-Uo; Wed, 09 Aug 2006 04:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAjqW-0006Jo-C6; Wed, 09 Aug 2006 04:55:24 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAjqU-00060y-US; Wed, 09 Aug 2006 04:55:24 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k797tMVv020619; Wed, 9 Aug 2006 10:55:22 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 11:55:21 +0300 Received: from esdhcp035153.research.nokia.com ([172.21.35.153]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Aug 2006 11:55:20 +0300 Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound From: Aki Niemi To: "ext sip-bounces@ietf.org" Cc: sip@ietf.org In-Reply-To: <200608090338.k793cSTC012965@dragon.ariadne.com> References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <200608090338.k793cSTC012965@dragon.ariadne.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Wed, 09 Aug 2006 11:55:20 +0300 Message-Id: <1155113720.16458.33.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2006 08:55:20.0994 (UTC) FILETIME=[8B64F820:01C6BB91] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ti, 2006-08-08 kello 23:38 -0400, ext sip-bounces@ietf.org kirjoitti: > From: Aki Niemi > > Seems outbound uses it to guarantee uniqueness of flows in a registrar, > but to me it sounds weird that the task of acquiring unique IDs within > the registrar's internal state is left to the UA -- after all, browsers > don't generally generate cookies themselves but store whatever the > website gives them. > > I believe the presupposition is that the common case will be a > physical "SIP telephone". It already must have a unique MAC address, > and there is a simple, defined way to turn that into a URN. So it is > assumed to be simpler for the device to generate an ID for itself from > its MAC address than for it to get and remember the ID given to it by > a registrar. I don't agree with that assumption. I am willing to bet softphones (ranging from Java apps in mobile phones to desktop softphones) probably outnumber blackphones already now, and definitely in the future. It's a mistake to optimize for a niche product, IMHO. Cheers, Aki _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 10:37:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApAF-0008Ec-DE; Wed, 09 Aug 2006 10:36:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApAD-0008EN-4j for sip@ietf.org; Wed, 09 Aug 2006 10:36:05 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GApAB-0000gg-QG for sip@ietf.org; Wed, 09 Aug 2006 10:36:05 -0400 Received: from [206.176.144.213] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k79EcEY0029507 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 9 Aug 2006 09:38:14 -0500 In-Reply-To: <1155113399.16458.27.camel@macbuster.research.nokia.com> References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44D91E3C.6020204@softarmor.com> <1155113399.16458.27.camel@macbuster.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CB5B0AC-F06D-4E9B-83B7-299146798CB1@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound Date: Wed, 9 Aug 2006 09:35:59 -0500 To: Aki Niemi X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 3:49 AM, Aki Niemi wrote: > ti, 2006-08-08 kello 18:29 -0500, ext Dean Willis kirjoitti: >> >> The only way we could come up with to do this (that didn't require >> eternal state in the registrar) was to make the assigned GRUU >> dependent >> on a transformation of "something unique to the client". > > Actually, this is completely orthogonal to the issue of who generates > this "something". > > Similarly, I can make a website that never expires cookies. > Persistence > there doesn't require browsers issuing any kind of unique IDs; > browsers > simply need to store the cookies they receive and offer them to > sites as > necessary. > Assume the browser loses the cookie and the server loses the authentication record. How does the web site know to issue the exact same cookie the next time the browser connects? > > But sip-outbound doesn't even have this immortality model. > Ah, I thought we were talking GRUU. > The pattern in SIP outbound is that of web cookies. I think it's not > good design to ignore that pattern and go with yet another approach > that > kind of does the same and might work, too. > > I see at least three problems with sip-outbound's use of the UUID URN: > > 1) It's generally a bad idea (and a security risk) to rely on the UA > generating data to be used in registrar-internal state lookups. > Even if > the UUID seems all dandy and easy to use in database lookups, I'd > still > prefer to decide exactly with which data I populate my own database > that > holds my own internal state. > > 2) Generating a UUID is yet another obscure specification to read, > interpret correctly and implement. I fear implementations won't get > this > right, and the registrar will simply have to make due with crappy > instance IDs UAs are giving it. It has no other choice, even when > those > IDs are generated my malicious UAs that intentionally look for > collisions. But if we're already doing all this for GRUU, why not just use the same thing? The "malicious UA" thing is interesting. It might apply to GRUU as well. I haven't thought about this. Anybody out there think it though yet? -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 11:05:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApac-0006SO-Su; Wed, 09 Aug 2006 11:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApab-0006SJ-Jd for sip@ietf.org; Wed, 09 Aug 2006 11:03:21 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GApaY-00045K-QI for sip@ietf.org; Wed, 09 Aug 2006 11:03:21 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 518181A7C29 for ; Wed, 9 Aug 2006 17:03:17 +0200 (CEST) Received: from [192.168.1.38] ([192.168.1.38]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:02:13 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0590a1057c40fa96aee3d22cb551fb87@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 17:03:49 +0200 To: Rohan Mahy X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 09 Aug 2006 15:02:13.0174 (UTC) FILETIME=[CBAD1560:01C6BBC4] X-Spam-Score: 1.8 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't like this proposal. I'm still with the camp that says: if configured, then it must be true. My main objection is that in this proposal, you are required to send SIP messages before STUN messages. That's a mandate that I'm not comfortable with since I might want to send STUN first to discover my public IP/port to populate the contact header before I send the first REGISTER. Hisham On Aug 8, 2006, at 4:38 PM, Rohan Mahy wrote: > > We had a very long discussion in Montreal about discovery and > validation of a SIP outbound proxy server's ability to receive STUN > requests. While the vast majority of the room was comfortable that > "keepalive=stun" in a URI was a sufficient indicator that an outbound > proxy supports SIP and STUN over the same port, a small but extremely > vocal minority had significant problems with this assumption. After a > discussion with Dean, I am willing to try a validation proposal which > adds no extra round trips if the SIP UA was indeed correctly > configured. > > The specific proposal works like this. A UAC which has an outbound > URI indicating with ;keepalive=stun that the next hop can support STUN > messages on the SIP port, needs to verify the first hop supports STUN > before sending any STUN messages. The UAC sends its first SIP message > to the next hop with a Proxy-Require: sip-stun. If the URI was > correct (STUN was supported), and the first-hop is an intermediary, > the first-hop removes the Proxy-Require and forwards the SIP request > (probably a REGISTER request) along adding no additional delay. A > positive response to a REGISTER or OPTIONS with Supported: outbound > and no error counts as positive confirmation that either the registrar > supports STUN or expects to never receive a request without getting it > from an outbound proxy which did not complain about the Proxy-Require > [1]. If the UAC was misconfigured (the first-hop intermediary does not > support STUN keepalives), either the first hop will reject the SIP > request (if it is an intermediary), or the registrar will not include > an indicator that it supports outbound (if the first hop was the > registrar). > > Note that this proposal is not a full *discovery* mechanism, just a > verification mechanism. For example, if the registrar doesn't support > outbound, but the first-hop does, there is no way described here to > discover that the first-hop can accept STUN keepalives. Do not > confuse support of STUN with support of outbound. Supported: outbound > implies that the registrar supports STUN or is configured to use an > outbound proxy that does. The sip-stun option tag only means that you > can send and receive STUN requests on your SIP port. While outbound > requires STUN, STUN does not require outbound. > > [1] Also Note that there is a caveat that you can still shoot yourself > in the foot if you allow messages to come straight to your registrar > that does not support STUN. I think we agreed that we are not going > to enumerate all the ways you can subtly break things in SIP though. > > thanks, > -rohan > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 11:08:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApeD-0008DK-2X; Wed, 09 Aug 2006 11:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApeB-0008DF-81 for sip@ietf.org; Wed, 09 Aug 2006 11:07:03 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GApe9-0004Ny-FR for sip@ietf.org; Wed, 09 Aug 2006 11:07:03 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DBFB74F004F; Wed, 9 Aug 2006 17:07:00 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:07:00 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:07:00 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 17:06:59 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12F4@esealmw113.eemea.ericsson.se> In-Reply-To: <0590a1057c40fa96aee3d22cb551fb87@telio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca7xPuG44Wk8RYuRJefsgTRPp4nRwAAFiRQ From: "Christer Holmberg \(JO/LMF\)" To: "Hisham Khartabil" , "Rohan Mahy" X-OriginalArrivalTime: 09 Aug 2006 15:07:00.0131 (UTC) FILETIME=[76B73F30:01C6BBC5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I don't like this proposal. I'm still with the camp that says: if configured, then it must be true. > >My main objection is that in this proposal, you are required to send SIP messages before STUN messages. That's a mandate=20 >that I'm not comfortable with since I might want to send STUN first to discover my public IP/port to populate the contact=20 >header before I send the first REGISTER. Is the public IP/port discovery part of the STUN usage for keep-alive? Regards, Christer > > We had a very long discussion in Montreal about discovery and=20 > validation of a SIP outbound proxy server's ability to receive STUN=20 > requests. While the vast majority of the room was comfortable that=20 > "keepalive=3Dstun" in a URI was a sufficient indicator that an = outbound=20 > proxy supports SIP and STUN over the same port, a small but extremely=20 > vocal minority had significant problems with this assumption. After a > discussion with Dean, I am willing to try a validation proposal which=20 > adds no extra round trips if the SIP UA was indeed correctly=20 > configured. > > The specific proposal works like this. A UAC which has an outbound=20 > URI indicating with ;keepalive=3Dstun that the next hop can support = STUN > messages on the SIP port, needs to verify the first hop supports STUN=20 > before sending any STUN messages. The UAC sends its first SIP message=20 > to the next hop with a Proxy-Require: sip-stun. If the URI was=20 > correct (STUN was supported), and the first-hop is an intermediary,=20 > the first-hop removes the Proxy-Require and forwards the SIP request=20 > (probably a REGISTER request) along adding no additional delay. A=20 > positive response to a REGISTER or OPTIONS with Supported: outbound=20 > and no error counts as positive confirmation that either the registrar > supports STUN or expects to never receive a request without getting it > from an outbound proxy which did not complain about the Proxy-Require=20 > [1]. If the UAC was misconfigured (the first-hop intermediary does not > support STUN keepalives), either the first hop will reject the SIP=20 > request (if it is an intermediary), or the registrar will not include=20 > an indicator that it supports outbound (if the first hop was the=20 > registrar). > > Note that this proposal is not a full *discovery* mechanism, just a=20 > verification mechanism. For example, if the registrar doesn't support > outbound, but the first-hop does, there is no way described here to=20 > discover that the first-hop can accept STUN keepalives. Do not=20 > confuse support of STUN with support of outbound. Supported: outbound > implies that the registrar supports STUN or is configured to use an=20 > outbound proxy that does. The sip-stun option tag only means that you > can send and receive STUN requests on your SIP port. While outbound=20 > requires STUN, STUN does not require outbound. > > [1] Also Note that there is a caveat that you can still shoot yourself > in the foot if you allow messages to come straight to your registrar=20 > that does not support STUN. I think we agreed that we are not going=20 > to enumerate all the ways you can subtly break things in SIP though. > > thanks, > -rohan > > > _______________________________________________ > Sip mailing list https://www1.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 > _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 11:10:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApfq-0000i7-UC; Wed, 09 Aug 2006 11:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApfp-0000fH-2e for sip@ietf.org; Wed, 09 Aug 2006 11:08:45 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GApfn-0004TX-G3 for sip@ietf.org; Wed, 09 Aug 2006 11:08:45 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id BB9631A840B for ; Wed, 9 Aug 2006 17:08:42 +0200 (CEST) Received: from [192.168.1.38] ([192.168.1.38]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:07:38 +0200 In-Reply-To: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> References: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 17:09:14 +0200 To: Dean Willis X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 09 Aug 2006 15:07:38.0587 (UTC) FILETIME=[8DA32AB0:01C6BBC5] X-Spam-Score: 1.8 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 8, 2006, at 10:02 PM, Dean Willis wrote: > > On Aug 8, 2006, at 9:38 AM, Rohan Mahy wrote: > >> >> The specific proposal works like this. A UAC which has an outbound >> URI indicating with ;keepalive=stun that the next hop can support >> STUN messages on the SIP port, needs to verify the first hop supports >> STUN before sending any STUN messages. The UAC sends its first SIP >> message to the next hop with a Proxy-Require: sip-stun. If the URI >> was correct (STUN was supported), and the first-hop is an >> intermediary, the first-hop removes the Proxy-Require and forwards >> the SIP request (probably a REGISTER request) along adding no >> additional delay. A positive response to a REGISTER or OPTIONS with >> Supported: outbound and no error counts as positive confirmation that >> either the registrar supports STUN or expects to never receive a >> request without getting it from an outbound proxy which did not >> complain about the Proxy-Require [1]. If the UAC was misconfigured >> (the first-hop intermediary does not support STUN keepalives), either >> the first hop will reject the SIP request (if it is an intermediary), >> or the registrar will not include an indicator that it supports >> outbound (if the first hop was the registrar). >> > > Cullen suggested an alternate possibility that might work. > > I'll try and paraphrase: > > A UAC which has an outbound URI indicating with ;keepalive=stun that > the next hop can support STUN messages on the SIP port needs to verify > the first hop supports STUN before repeatedly sending STUN messages. > The UAC may initially try sending STUN messages to the SIP port of the > first hop node. If the UAC does not receive a correct STUN response > (within some timer?) then it must assume that this mode does not > support STUN, and proceed without using STUN until it has some > evidence that the first-hop node might have changed, in which case it > retries the STUN requests as per the initial attempt. > > I think it's probably okay to stun a server a few times before > deciding it doesn't like being stunned -- after all, the primary risk > is one of slowing down service for the user doing the stunning, not > shutting down the server being stunned. What I object to is a > specification that says you go on stunning it indefinitely, perhaps > millions of times over the course of an association, with no way to > discover that you really shouldn't be stunning it. This is ok. Nothing special here. This is default behaviour anyway even if you assume that ;keepalive=stun is true. You need some sort of recovery mechanism from misconfiguration. But I think this is an implementation issue and not anything normative. Hisham > > Set phasers on "stun", Mr. Sulu! > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 11:44:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAqCE-0003lx-FE; Wed, 09 Aug 2006 11:42:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAqCC-0003lr-Nj for sip@ietf.org; Wed, 09 Aug 2006 11:42:12 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAqCB-00014J-8M for sip@ietf.org; Wed, 09 Aug 2006 11:42:12 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k79FfwF06804; Wed, 9 Aug 2006 08:41:58 -0700 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F12F4@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F12F4@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <810dc06cabec38192283892b965e196b@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 08:42:23 -0700 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, I think your question is off topic for this thread. Are you asking about "Outbound Issues: slide 7"? I think the answer to your question is no, but I'm not 100% sure what you are asking. thanks, -rohan On Aug 9, 2006, at 8:06, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >> I don't like this proposal. I'm still with the camp that says: if > configured, then it must be true. >> >> My main objection is that in this proposal, you are required to send > SIP messages before STUN messages. That's a mandate >> that I'm not comfortable with since I might want to send STUN first to > discover my public IP/port to populate the contact >> header before I send the first REGISTER. > > Is the public IP/port discovery part of the STUN usage for keep-alive? > > Regards, > > Christer > > > > >> >> We had a very long discussion in Montreal about discovery and >> validation of a SIP outbound proxy server's ability to receive STUN >> requests. While the vast majority of the room was comfortable that >> "keepalive=stun" in a URI was a sufficient indicator that an outbound >> proxy supports SIP and STUN over the same port, a small but extremely >> vocal minority had significant problems with this assumption. After a > >> discussion with Dean, I am willing to try a validation proposal which >> adds no extra round trips if the SIP UA was indeed correctly >> configured. >> >> The specific proposal works like this. A UAC which has an outbound >> URI indicating with ;keepalive=stun that the next hop can support STUN > >> messages on the SIP port, needs to verify the first hop supports STUN >> before sending any STUN messages. The UAC sends its first SIP message >> to the next hop with a Proxy-Require: sip-stun. If the URI was >> correct (STUN was supported), and the first-hop is an intermediary, >> the first-hop removes the Proxy-Require and forwards the SIP request >> (probably a REGISTER request) along adding no additional delay. A >> positive response to a REGISTER or OPTIONS with Supported: outbound >> and no error counts as positive confirmation that either the registrar > >> supports STUN or expects to never receive a request without getting it > >> from an outbound proxy which did not complain about the Proxy-Require >> [1]. If the UAC was misconfigured (the first-hop intermediary does not > >> support STUN keepalives), either the first hop will reject the SIP >> request (if it is an intermediary), or the registrar will not include >> an indicator that it supports outbound (if the first hop was the >> registrar). >> >> Note that this proposal is not a full *discovery* mechanism, just a >> verification mechanism. For example, if the registrar doesn't support > >> outbound, but the first-hop does, there is no way described here to >> discover that the first-hop can accept STUN keepalives. Do not >> confuse support of STUN with support of outbound. Supported: outbound > >> implies that the registrar supports STUN or is configured to use an >> outbound proxy that does. The sip-stun option tag only means that you > >> can send and receive STUN requests on your SIP port. While outbound >> requires STUN, STUN does not require outbound. >> >> [1] Also Note that there is a caveat that you can still shoot yourself > >> in the foot if you allow messages to come straight to your registrar >> that does not support STUN. I think we agreed that we are not going >> to enumerate all the ways you can subtly break things in SIP though. >> >> thanks, >> -rohan >> >> >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 11:46:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAqEr-00050h-En; Wed, 09 Aug 2006 11:44:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAqEp-0004ww-Bt for sip@ietf.org; Wed, 09 Aug 2006 11:44:55 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAqEn-0002px-IR for sip@ietf.org; Wed, 09 Aug 2006 11:44:55 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EC15D4F000F; Wed, 9 Aug 2006 17:44:52 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:44:52 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:44:51 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 17:44:51 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12F7@esealmw113.eemea.ericsson.se> In-Reply-To: <810dc06cabec38192283892b965e196b@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca7ymbCo5FAXPlTRuOKQyZOGjAHvgAABk4g From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 09 Aug 2006 15:44:51.0590 (UTC) FILETIME=[C09C6260:01C6BBCA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, Isn't STUN usage for IP port/discovery (as mentioned by Hisham) off topic? Regards, Christer=20 -----Original Message----- From: Rohan Mahy [mailto:rohan@ekabal.com]=20 Sent: 9. elokuuta 2006 18:42 To: Christer Holmberg (JO/LMF) Cc: Hisham Khartabil; Rohan Mahy; IETF SIP List Subject: Re: [Sip] Outbound Issues: slides 3 and 4=20 Hi Christer, I think your question is off topic for this thread. Are you asking about "Outbound Issues: slide 7"? I think the answer to your question is no, but I'm not 100% sure what you are asking. thanks, -rohan On Aug 9, 2006, at 8:06, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >> I don't like this proposal. I'm still with the camp that says: if > configured, then it must be true. >> >> My main objection is that in this proposal, you are required to send > SIP messages before STUN messages. That's a mandate >> that I'm not comfortable with since I might want to send STUN first=20 >> to > discover my public IP/port to populate the contact >> header before I send the first REGISTER. > > Is the public IP/port discovery part of the STUN usage for keep-alive? > > Regards, > > Christer > > > > >> >> We had a very long discussion in Montreal about discovery and=20 >> validation of a SIP outbound proxy server's ability to receive STUN=20 >> requests. While the vast majority of the room was comfortable that=20 >> "keepalive=3Dstun" in a URI was a sufficient indicator that an = outbound >> proxy supports SIP and STUN over the same port, a small but extremely >> vocal minority had significant problems with this assumption. After=20 >> a > >> discussion with Dean, I am willing to try a validation proposal which >> adds no extra round trips if the SIP UA was indeed correctly=20 >> configured. >> >> The specific proposal works like this. A UAC which has an outbound=20 >> URI indicating with ;keepalive=3Dstun that the next hop can support=20 >> STUN > >> messages on the SIP port, needs to verify the first hop supports STUN >> before sending any STUN messages. The UAC sends its first SIP message >> to the next hop with a Proxy-Require: sip-stun. If the URI was=20 >> correct (STUN was supported), and the first-hop is an intermediary,=20 >> the first-hop removes the Proxy-Require and forwards the SIP request=20 >> (probably a REGISTER request) along adding no additional delay. A=20 >> positive response to a REGISTER or OPTIONS with Supported: outbound=20 >> and no error counts as positive confirmation that either the=20 >> registrar > >> supports STUN or expects to never receive a request without getting=20 >> it > >> from an outbound proxy which did not complain about the Proxy-Require >> [1]. If the UAC was misconfigured (the first-hop intermediary does=20 >> not > >> support STUN keepalives), either the first hop will reject the SIP=20 >> request (if it is an intermediary), or the registrar will not include >> an indicator that it supports outbound (if the first hop was the=20 >> registrar). >> >> Note that this proposal is not a full *discovery* mechanism, just a=20 >> verification mechanism. For example, if the registrar doesn't=20 >> support > >> outbound, but the first-hop does, there is no way described here to=20 >> discover that the first-hop can accept STUN keepalives. Do not=20 >> confuse support of STUN with support of outbound. Supported:=20 >> outbound > >> implies that the registrar supports STUN or is configured to use an=20 >> outbound proxy that does. The sip-stun option tag only means that=20 >> you > >> can send and receive STUN requests on your SIP port. While outbound=20 >> requires STUN, STUN does not require outbound. >> >> [1] Also Note that there is a caveat that you can still shoot=20 >> yourself > >> in the foot if you allow messages to come straight to your registrar=20 >> that does not support STUN. I think we agreed that we are not going=20 >> to enumerate all the ways you can subtly break things in SIP though. >> >> thanks, >> -rohan >> >> >> _______________________________________________ >> Sip mailing list https://www1.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 >> > > > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 12:36:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAr1M-0000uf-Lp; Wed, 09 Aug 2006 12:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAr1K-0000p7-U5 for sip@ietf.org; Wed, 09 Aug 2006 12:35:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GApSs-0003Cw-8r for sip@ietf.org; Wed, 09 Aug 2006 10:55:22 -0400 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GApHw-0005l6-Ht for sip@ietf.org; Wed, 09 Aug 2006 10:44:05 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc15) with ESMTP id <2006080914440201500dv1pte>; Wed, 9 Aug 2006 14:44:02 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k79Ei1eY028723 for ; Wed, 9 Aug 2006 10:44:01 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k79Ei1IS028719; Wed, 9 Aug 2006 10:44:01 -0400 Date: Wed, 9 Aug 2006 10:44:01 -0400 Message-Id: <200608091444.k79Ei1IS028719@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1155113720.16458.33.camel@macbuster.research.nokia.com> (aki.niemi@nokia.com) Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <200608090338.k793cSTC012965@dragon.ariadne.com> <1155113720.16458.33.camel@macbuster.research.nokia.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Aki Niemi I don't agree with that assumption. I am willing to bet softphones (ranging from Java apps in mobile phones to desktop softphones) probably outnumber blackphones already now, and definitely in the future. It's a mistake to optimize for a niche product, IMHO. Perhaps so. But in that case, a UA can generate a pseudo-random URN. In either case, it's simpler for the UA to generate a URN for itself than to execute protocol operations to obtain and save one. And that avoids adding Yet Another Feature to SIP. Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 12:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArBd-0006qS-Ow; Wed, 09 Aug 2006 12:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArBc-0006qN-H4 for sip@ietf.org; Wed, 09 Aug 2006 12:45:40 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GArBb-000663-Jj for sip@ietf.org; Wed, 09 Aug 2006 12:45:40 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B5FC96E0001; Wed, 9 Aug 2006 18:45:38 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 18:45:37 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 18:45: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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 18:45:37 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12F8@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0C184D04@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca6+FvmrwPGJkN2QEeK2pW3HBAA0wAGTe/AADBFPIA= From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Rohan Mahy" , "IETF SIP List" X-OriginalArrivalTime: 09 Aug 2006 16:45:37.0403 (UTC) FILETIME=[3DAF4CB0:01C6BBD3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, If the UAC wants to make sure that the next-hop proxy (may or may not support outbound, since STUN keep-alive is a separate function) supports STUN keep-alive, it can insert a Proxy-Require option-tag. But, why can't the next-hop proxy, if it supports STUN keep-alive, insert a Path header with "keepalive=3Dstun"? That would tell the UAC, when it receives the REGISTER response (assuming it contains the Path headers) that the proxy supports STUN keepalive. (This would of course require that the proxy supports Path). I also think we need to remember that, since STUN keep-alive is now separated from outbound, the UAC may not have any outbound URIs (as defined by the outbound draft). Regards, Christer =20 -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: 8. elokuuta 2006 21:47 To: Rohan Mahy; IETF SIP List Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Rohan, I really like the idea of decoupling sip-stun support, versus outbound support. But I'm findind the description quite complicated... I'm also wondering if the ";keep-alive=3Dstun" is still useful with the addition of the Proxy-Require: sip-stun. It doesn't seem to me that it is, except as an automatic configuration option for the UAC. Since the UAC certainly requires much more configuration options (with config-framework, or config files or whatever), I'm not sure it is worth the effort. I don't see why this one in particular is more important than any other. Let me try to paraphrase what you are saying, to make sure I understood it properly: - "Proxy-require: sip-stun" means that the outbound proxy is required to support sip-stun, i.e., the procedures of section 3.5. A consequence of this is that it precludes deployments where the sip-stun is supported not in the first hop, but later (e.g., the Registrar), but with some other intermedia proxy between. - "Supported: outbound" means that the Registrar supports the procedures of the draft that are not related to sip-stun. - ";keep-alive=3Dstun" is an indication for the UAC that stun-in-sip is supported by the network. Essentially an autoconfiguration option. We have been using terms like "edge proxy", "outbound proxy" now "first hop", and "intermediary". To me, it seems that there are only two entities that are relevant here: 1 - The outbound proxy. This is where all requests are sent, and the entity that terminates sip-in-stun. 2 - The Registrar. Also the entity that supports the "Outbound" procedures (excluding stun-in-sip). A very common scenario is where 1 & 2 are co-located. In this case the Registrar is the oubound-proxy and it does terminate sip-stun. Also, I don't understand why your point [1] is a problem. Wouldn't a Registrar that doesn't support stun-sip, but which is accesses directly (i.e., as an outbound proxy) just reject the REGISTER because it contained "Proxy-Require: stun-sip" with 420 with "Unsupported: stun-sip"? Are you worried that such a REGISTRAR may not believe the Proxy-Require was intended for itself? > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com] > Sent: Tuesday, August 08, 2006 7:39 AM > To: IETF SIP List > Cc: Rohan Mahy > Subject: [Sip] Outbound Issues: slides 3 and 4 >=20 >=20 > We had a very long discussion in Montreal about discovery and=20 > validation of a SIP outbound proxy server's ability to receive STUN=20 > requests. While the vast majority of the room was comfortable that=20 > "keepalive=3Dstun" in a URI was a sufficient indicator that an = outbound=20 > proxy supports SIP and STUN over the same port, a small but extremely=20 > vocal minority had significant problems with this assumption. After a > discussion with Dean, I am willing to try a validation proposal which=20 > adds no extra round trips if the SIP UA was indeed correctly=20 > configured. >=20 > The specific proposal works like this. A UAC which has an outbound=20 > URI indicating with ;keepalive=3Dstun that the next hop can support = STUN > messages on the SIP port, needs to verify the first hop supports STUN=20 > before sending any STUN messages. The UAC sends its first SIP message=20 > to the next hop with a Proxy-Require: sip-stun. If the URI was=20 > correct (STUN was supported), and the first-hop is an intermediary,=20 > the first-hop removes the Proxy-Require and forwards the SIP request=20 > (probably a REGISTER request) along adding no additional delay. A=20 > positive response to a REGISTER or OPTIONS with Supported: outbound=20 > and no error counts as positive confirmation that either the registrar > supports STUN or expects to never receive a request without getting it > from an outbound proxy which did not complain about the Proxy-Require=20 > [1]. If the UAC was misconfigured (the first-hop intermediary does not > support STUN keepalives), either the first hop will reject the SIP=20 > request (if it is an intermediary), or the registrar will not include=20 > an indicator that it supports outbound (if the first hop was the=20 > registrar). >=20 > Note that this proposal is not a full *discovery* mechanism, just a=20 > verification mechanism. For example, if the registrar doesn't support > outbound, but the first-hop does, there is no way described here to=20 > discover that the first-hop can accept STUN keepalives. Do not=20 > confuse support of STUN with support of outbound. Supported: outbound > implies that the registrar supports STUN or is configured to use an=20 > outbound proxy that does. The sip-stun option tag only means that you > can send and receive STUN requests on your SIP port. While outbound=20 > requires STUN, STUN does not require outbound. >=20 > [1] Also Note that there is a caveat that you can still shoot yourself > in the foot if you allow messages to come straight to your registrar=20 > that does not support STUN. I think we agreed that we are not going=20 > to enumerate all the ways you can subtly break things in SIP though. >=20 > thanks, > -rohan >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 12:48:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArCT-0007HW-Q7; Wed, 09 Aug 2006 12:46:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArCS-0007HR-Vo for sip@ietf.org; Wed, 09 Aug 2006 12:46:32 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GArCQ-0006Q0-8T for sip@ietf.org; Wed, 09 Aug 2006 12:46:32 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A42BC6E0001; Wed, 9 Aug 2006 18:46:29 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 18:46:29 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 18:46:29 +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 Subject: RE: [Sip] Outbound issues: slides 9 and 10 - Why does every proxy need to support outbound? Date: Wed, 9 Aug 2006 18:46:28 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12F9@esealmw113.eemea.ericsson.se> In-Reply-To: <6c91a88d048a5acea156de16a7f4fe44@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound issues: slides 9 and 10 - Why does every proxy need to support outbound? Thread-Index: Aca6+FyGS4/hrWBeQcCSra9fxXAQ5wAt2rWw From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" , "IETF SIP List" X-OriginalArrivalTime: 09 Aug 2006 16:46:29.0030 (UTC) FILETIME=[5C74F460:01C6BBD3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, A couple of questions: >The issues on slide 9 (how does a registrar verify that an edge proxy supports outbound) and slide 10 (what does >"Supported: outbound" mean) deal with detecting that all the required hops support outbound. Slide >9 specifically uncovered a problem with outbound proxies that add a Path URI but don't include a flow token. > >The proposed solution is as follows. If a proxy inserts a Path header with a flow token consistent with the rules d >escribed in outbound, it MUST add the ;ob parameter to the proxy URI that has the flow token. > >The registrar verifies that any Path header URIs contain the ;ob parameter. If there are any Path URIs without the ob=20 >parameter, the registrar does not return Supported: outbound. [CHH] Why would every Path header need to contain the ;ob parameter? The REGISTER request may traverse, in addition to the outbound proxy, multiple proxies which insert a Path header. Do all these proxies really need to support outbound? >Furthermore, the registrar needs to check that the first hop after the UAC is represented in the Path list (unless the=20 >registrar recognizes that the first hop after the UAC is in the same domain and doesn't need to include Path URIs with a=20 >flow token). Note that this implies that whatever the proxy puts in the Via (IP address or FQDN), it must put the same=20 >hostname in the Path header (but there is no need for a complete URI comparison). If the first hop is not correctly=20 >represented, the registrar ignores the reg-id parameter and does not return Supported: outbound. [CHH] Isn't it much easier to mandate the outbound proxy to always insert a Path header? OR, another possibility is that the outbound proxy, if it detects that the UAC supports outbound, insert some option-tag of itself in the Supported header, to indicate to the registrar that it supports outbound. Then the registrar does not need start looking at the Path headers. Regards, Christer The implication of this is that an outbound-proxy that supports outbound needs to support Path and flow tokens for registrations to all foreign domains. Inside the same domain, the first-hop proxy and the registrar can still use Path to communicate with each other, but they can use some other private mechanism to disaggregate this functionality. thanks, -rohan _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 12:51:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArFA-0000F2-11; Wed, 09 Aug 2006 12:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArF7-0000Es-O5 for sip@ietf.org; Wed, 09 Aug 2006 12:49:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GArF6-0007ZA-DJ for sip@ietf.org; Wed, 09 Aug 2006 12:49:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2006 12:49:16 -0400 X-IronPort-AV: i="4.08,107,1154923200"; d="scan'208"; a="95884543:sNHT26252276" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79GnGhN025498; Wed, 9 Aug 2006 12:49:16 -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.12.10/8.12.6) with ESMTP id k79GnEdr005886; Wed, 9 Aug 2006 12:49:15 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 12:49:15 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 12:49:14 -0400 Message-ID: <44DA120A.1090107@cisco.com> Date: Wed, 09 Aug 2006 12:49:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44D91E3C.6020204@softarmor.com> <1155113399.16458.27.camel@macbuster.research.nokia.com> <2CB5B0AC-F06D-4E9B-83B7-299146798CB1@softarmor.com> In-Reply-To: <2CB5B0AC-F06D-4E9B-83B7-299146798CB1@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2006 16:49:14.0771 (UTC) FILETIME=[BF3F0630:01C6BBD3] DKIM-Signature: a=rsa-sha1; q=dns; l=3292; t=1155142156; x=1156006156; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Question=20regarding=20instance=20ID=20in=20GRUU=20and=2 0outbound |To:Dean=20Willis=20; X=v=3Dcisco.com=3B=20h=3DOa/VNwPzdLqO79eqZZ6+DMJpgWI=3D; b=zivfLdE/NpBikQs46svwu73yN333a2ecMqbVRVz/hqMtrqo6x2m/r5zfIOu2CKZ1Eo8kNlZ/ Wa4h1xw/5bdaMtqxHPA/rlr9O3vZc4sJ8ClnhN6ctGjZzrTPSOo+3xX9; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sip , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Historically, the instance id was first introduced for GRUU. Then it was adopted for use in outbound. Then the dependencies were inverted, with outbound providing the definition of instance id and gruu referencing it. In theory they could use different techniques, though the value of that seems dubious to me. If they both use the same id, then it has to meet both of their needs. As things stand it does. If it were to be changed to a cookie supplied by the registrar, then its unclear if it could as well meet both sets of needs. At the moment the predominant need is to *get done*. The existing approach has a huge advantage on that score. Paul Dean Willis wrote: > > On Aug 9, 2006, at 3:49 AM, Aki Niemi wrote: > >> ti, 2006-08-08 kello 18:29 -0500, ext Dean Willis kirjoitti: >>> >>> The only way we could come up with to do this (that didn't require >>> eternal state in the registrar) was to make the assigned GRUU dependent >>> on a transformation of "something unique to the client". >> >> Actually, this is completely orthogonal to the issue of who generates >> this "something". >> >> Similarly, I can make a website that never expires cookies. Persistence >> there doesn't require browsers issuing any kind of unique IDs; browsers >> simply need to store the cookies they receive and offer them to sites as >> necessary. >> > > Assume the browser loses the cookie and the server loses the > authentication record. > > How does the web site know to issue the exact same cookie the next time > the browser connects? >> >> But sip-outbound doesn't even have this immortality model. >> > > Ah, I thought we were talking GRUU. > >> The pattern in SIP outbound is that of web cookies. I think it's not >> good design to ignore that pattern and go with yet another approach that >> kind of does the same and might work, too. >> >> I see at least three problems with sip-outbound's use of the UUID URN: >> >> 1) It's generally a bad idea (and a security risk) to rely on the UA >> generating data to be used in registrar-internal state lookups. Even if >> the UUID seems all dandy and easy to use in database lookups, I'd still >> prefer to decide exactly with which data I populate my own database that >> holds my own internal state. >> >> 2) Generating a UUID is yet another obscure specification to read, >> interpret correctly and implement. I fear implementations won't get this >> right, and the registrar will simply have to make due with crappy >> instance IDs UAs are giving it. It has no other choice, even when those >> IDs are generated my malicious UAs that intentionally look for >> collisions. > > But if we're already doing all this for GRUU, why not just use the same > thing? > > The "malicious UA" thing is interesting. It might apply to GRUU as well. > I haven't thought about this. > > Anybody out there think it though yet? > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 13:36:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArxC-0000cv-EV; Wed, 09 Aug 2006 13:34:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArxA-0000Zh-7y for sip@ietf.org; Wed, 09 Aug 2006 13:34:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GArx9-0005tZ-LZ for sip@ietf.org; Wed, 09 Aug 2006 13:34:48 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2006 10:34:46 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="310710209:sNHT32276822" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79HYkmd032427; Wed, 9 Aug 2006 10:34:46 -0700 Received: from [192.168.1.2] (sjc-vpn4-506.cisco.com [10.21.81.250]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79HYjIZ021712; Wed, 9 Aug 2006 10:34:46 -0700 (PDT) In-Reply-To: <44D90A7D.1030303@lucent.com> References: <44ADE168.7050309@cisco.com> <44AF59A8.1000304@lucent.com> <77482B40-90DF-43A7-BC76-07EA1AF05C52@cisco.com> <44D90A7D.1030303@lucent.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28C1FAA8-8E9A-42C0-9C44-DF771089F110@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] comments on draft-ietf-sip-connect-reuse-05 Date: Wed, 9 Aug 2006 10:34:30 -0700 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=6896; t=1155144886; x=1156008886; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-connect-reuse-05; X=v=3Dcisco.com=3B=20h=3DGR+QyU0oZVkbvnn5V1JEI8Vyl0w=3D; b=bkB9fp6HOU1oCamIcrYPpix9OkMtfECg6ieiQg8/Wji4i7QAFrvA3l9DaeeMegx29uqYs5GD +306vMCwBzR1XeGKS0wISdBDzK0EH7pEmm8oc2x18lFWv3qmy38f5qf2; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes - this solves it. The key thing is the table has to store the name (or names) from the TLS cert and that when you go to reuse the connection, you can only reuse it if the target you are sending to if it matches this name from the cert. Now, assuming we did this, it brings up some other questions which I don't really feel that strongly about - why bother storing the IP and port in the table? If you have a connection to that domain, just use it. I realize that stops the distribution of load from a single proxy to farm but it's not clear to me if that is a bug or a feature. If the goal is to reduce number of connections and still have reliability - it is a feature. If you have a bunch of proxies all sending to a bunch of proxies, they will likely end up somewhat load balanced anyways. It would significantly reduce the complexity of this draft to describe it that way. I'm ok with the draft going any one of the following direction on this 1) always do all the DNS stuff resulting in O(n^2) connection between two farms that both had n proxies 2) don't keep the IP and port in the table resulting in O(n) connection between two farms that both had n proxies 3) let it be an configurable option. No matter what way we go, your proposal here solves the security problem and I like it. Thanks, Cullen On Aug 8, 2006, at 3:04 PM, Vijay K. Gurbani wrote: > Cullen Jennings wrote: >> Big question ... > [...] >> I don't think this works from some TLS situations. If a proxy is >> hosting two virtual domain red and blue both with TLS and use the >> same port for both using the extended hellos TLS options. > > Cullen: Thanks for being persistent on this one. This situation > was listed as an open issue at the Dallas IETF presentation > (see http://www3.ietf.org/proceedings/06mar/slides/sip-6.pdf). > > So, I think we can solve this with some work. More inline; I > will preserve the description of the problem you provided for > context. > >> Now both the red and blue domains have a user called tel:1234 but we >> don't want red tel:1234 to get IMs meant for blue. Blue sends an IM >> to Alice at some other domain. This forms an alias to the server. >> Now Red bob sends an IM to Alice - this updates the alias and >> basically hijacks blue. When ALice relies to blue, the proxy in >> Alice's domain will mistakenly select the TLS connection that was >> formed by red domain since it goes to the correct ip address, port, >> and transport. The virtual domain that servers red and blue will >> process the request in the context of red since it received it over >> a TLS connection that is part of the red domain. You might say this >> is a corner case but hosting multiple virtual domains this way is >> very desirable and the HTTP people have been working hard to make >> this easier to deploy. The latest version of common TLS libraries >> are starting to support this and I expect to see more servers that >> can do this. (PS. I think I have mentioned this on several different >> versions of this document - let me know if I am not making any >> sense) > > In order to arrive at how to solve this, the idea from Jonathan's > email about a server caching client certificates for later > use come into the picture. Here are the steps: > > 1) We have a proxy P that has two virtual domains -- red.com > and blue.com -- accessible at port 5061 (note that in the > scenario we are talking about, the destination port really > does not matter. The problem arises when P sends *out* > requests from its respective domains to a third party, and > that third party wants to re-use the ensuing connection for > requests in the backwards direction). > > 1a) P has a physical address of 192.168.1.2. > > 2) red.com has a user with a URI of sip:bob@red.com. > > 3) blue.com has a user with a URI of sip:bob@blue.com. > > 4) Now, bob@blue.com sends out a request to Alice through P: > MESSAGE sips:alice@P2.com SIP/2.0 > From: ;tag=8uxy--y6 > Via: SIP/2.0/TLS blue.com;branch=... > ... > 5) Alice's proxy (P2) gets the request and creates an alias: > > Dest. Dest. Dest. Dest. Alias > Address Port Transport Certificate Descriptor > 192.168.1.2 5061 TLS blue.com 28 > > Note the new column (Dest. Certificate) -- this is key to > solving this particular problem. The certificate from > blue.com is cached by P2, and the domain name in the column is > got from either the Via, or better yet, from the SAN in the > certificate. > > Now requests from P2 towards the blue.com:5061 domain will go through > the alias descriptor 28, which is tied to 192.168.1.2:6666 (port > 6666 being the source port chosen by the sending TCP). > > 6) At some later time, bob@red.com sends a request to Alice through > P: > MESSAGE sips:alice@P2.com SIP/2.0 > From: ;tag=9j7-y6 > Via: SIP/2.0/TLS red.com;branch=... > ... > > 7) Alice's proxy (P2) gets the request and updates its alias > table with a new row: > > Dest. Dest. Dest. Dest. Alias > Address Port Transport Certificate Descriptor > 192.168.1.2 5061 TLS blue.com 28 > 192.168.1.2 5061 TLS red.com 32 > > Requests from P2 towards the red.com:5061 domain will go > through the alias descriptor 32, which is tied to 192.168.1.2:7777 > (port 7777 being the source port chosen by the sending TCP). > > 8) When P2 wants to send a request in the opposite direction, it > will run the next hop URI through rfc3263 resolution. That > resolution will result in an IP address/port/transport > (192.168.1.2:5061:TLS). But instead of simply sending it to > the first such row from the alias table, P2 will need to > authenticate the URI used in the rfc3263 resolution to the > appropriate certificate in order to choose the right descriptor. > > Thus, P knows that all requests coming in the backwards direction > over 192.168.1.2:6666 belong to blue.com and those arriving over > 192.168.1.2:7777 belong to red.com. > > I know this makes for a rather complex set of gyrations, but if > we want to support name-based virtual servers, then this is one > way that accounts for the requirements listed in Section 6 > of the connect-reuse draft. If there are better and more elegant > ways to do this, I would love to hear them. > > Thoughts? > > Thanks. > > - vijay > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 14:11:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsUf-0003CN-FI; Wed, 09 Aug 2006 14:09:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsUe-00038Q-7J for sip@ietf.org; Wed, 09 Aug 2006 14:09:24 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAsUc-00015Z-QJ for sip@ietf.org; Wed, 09 Aug 2006 14:09:24 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A4BE0560; Wed, 09 Aug 2006 14:09:02 -0400 From: "Hadriel Kaplan" To: "'Fredrik Thulin'" , Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 14:08:49 -0400 Message-ID: <00a801c6bbde$ddffa3d0$b7c8000a@acmepacket.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: <200608091036.43395.ft@it.su.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca7j0udmMihCya+RieUyy/SqFVOjwATbazQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'Rohan Mahy' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se] > Sent: Wednesday, August 09, 2006 4:37 AM > To: sip@ietf.org > Cc: Rohan Mahy; Dean Willis > Subject: Re: [Sip] Outbound Issues: slides 3 and 4 > > On Wednesday 09 August 2006 07:00, Rohan Mahy wrote: > ... > > I'm personally pretty happy with this, "if it ain't working, don't > > keep doing it approach." > > Could others comment if they like the approach or not? > > I am in favor of it, because ultimately there is no way to _know_ that > the first hop actually handles STUN requests without sending one. > > The argument that a response containing something saying "I claim I can > handle STUN requests you send me" is to be trusted, but configuration > saying ";keepalive=stun" is not is flawed. Au contraire. I would argue fairly vehemently that a server explicitly indicating it supports something is far more reliable than a UA believing the server supports something based on a local config setting. The former is an explicit indication by the guy who's responsible for doing that mechanism, whether he can do it or not; the latter is a guess by the client as to the other side's capabilities. Certainly the proxy can be wrong, but that probability is miniscule to the odds that one UA out of a large population will be wrong. > The UA will still have to > send a STUN request, and might or might not receive a response. It sure will. But if the proxy indicated support for sip-stun, that failure would only occur if the proxy implementation was broken. It would not be used as an active check mechanism. If the proxy is broken, it's under the power of the owner of the proxy to fix it. If the UAs send STUN every-time they boot-up or re-connect, it is not under the power of the owner of the proxy to stop them if the proxy cannot explicitly indicate support/not. > I consider blacklisting an IP address that sends you one (1) packet you > consider bad to be too aggressive. I wouldn't use a proxy that did > that. It won't be 1 packet. The UAC will have to retransmit multiple times, because as far as it knows packet loss happened. (btw, such proxies are typically highly configurable in how they detect and handle such things) -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 14:18:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsbt-0007aj-7N; Wed, 09 Aug 2006 14:16:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsbp-0007aL-7d for sip@ietf.org; Wed, 09 Aug 2006 14:16:49 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAsbn-0001WI-Md for sip@ietf.org; Wed, 09 Aug 2006 14:16:49 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2006 14:16:47 -0400 X-IronPort-AV: i="4.08,107,1154923200"; d="scan'208"; a="95899859:sNHT30302482" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79IGl5x003686; Wed, 9 Aug 2006 14:16:47 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k79IGldp002847; Wed, 9 Aug 2006 14:16:47 -0400 (EDT) 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); Wed, 9 Aug 2006 14:16:47 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 14:16:46 -0400 Message-ID: <44DA268E.5020209@cisco.com> Date: Wed, 09 Aug 2006 14:16:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] comments on draft-ietf-sip-connect-reuse-05 References: <44ADE168.7050309@cisco.com> <44AF59A8.1000304@lucent.com> <77482B40-90DF-43A7-BC76-07EA1AF05C52@cisco.com> <44D90A7D.1030303@lucent.com> <28C1FAA8-8E9A-42C0-9C44-DF771089F110@cisco.com> In-Reply-To: <28C1FAA8-8E9A-42C0-9C44-DF771089F110@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2006 18:16:46.0940 (UTC) FILETIME=[F9C869C0:01C6BBDF] DKIM-Signature: a=rsa-sha1; q=dns; l=8332; t=1155147407; x=1156011407; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-connect-reuse-05 |To:Cullen=20Jennings=20; X=v=3Dcisco.com=3B=20h=3Dwg4vAqODAgFZSqT5MgO4fQCl7CE=3D; b=kTJf4m36cJFeSCPylVK7LB3Ixgi62+un5gqaiUQjY0virIDFO7tPpR/hFz1BBGEF39IFznH2 5hlwRcByvx/8qjHR4ZcsGdTcEovj0xdaHRxo+j0aBXj6k9+Q5Hl/KRDg; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: IETF SIP List , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > Yes - this solves it. The key thing is the table has to store the name > (or names) from the TLS cert and that when you go to reuse the > connection, you can only reuse it if the target you are sending to if it > matches this name from the cert. (Sorry if this makes no sense - my knowledge of TLS is feeble.) I am confused by Vijay's example because it shows the entries for red.com and blue.com being established independently. They have the same address and port, and it isn't clear if they share a connection. I would think that Bob's proxy would only establish one connection to Alice's proxy, and that the TLS handshake would provide all the identities that Bob's proxy has. (red.com and blue.com) > Now, assuming we did this, it brings up some other questions which I > don't really feel that strongly about - why bother storing the IP and > port in the table? If you have a connection to that domain, just use it. > I realize that stops the distribution of load from a single proxy to > farm but it's not clear to me if that is a bug or a feature. I don't see how you can use any but the established connections in any case. You only have the identity via the handshake on the connection you have. If that goes away you will need to establish a new connection and exchange credentials again. The establishment will be driven by 3264 - no need for the table - and then a new table entry will be established. So I think you are right to only keep the connection in the table. Paul > If the goal > is to reduce number of connections and still have reliability - it is a > feature. If you have a bunch of proxies all sending to a bunch of > proxies, they will likely end up somewhat load balanced anyways. It > would significantly reduce the complexity of this draft to describe it > that way. I'm ok with the draft going any one of the following direction > on this 1) always do all the DNS stuff resulting in O(n^2) connection > between two farms that both had n proxies 2) don't keep the IP and port > in the table resulting in O(n) connection between two farms that both > had n proxies 3) let it be an configurable option. > > No matter what way we go, your proposal here solves the security problem > and I like it. > > Thanks, Cullen > > > On Aug 8, 2006, at 3:04 PM, Vijay K. Gurbani wrote: > >> Cullen Jennings wrote: >>> Big question ... >> [...] >>> I don't think this works from some TLS situations. If a proxy is >>> hosting two virtual domain red and blue both with TLS and use the >>> same port for both using the extended hellos TLS options. >> >> Cullen: Thanks for being persistent on this one. This situation >> was listed as an open issue at the Dallas IETF presentation >> (see http://www3.ietf.org/proceedings/06mar/slides/sip-6.pdf). >> >> So, I think we can solve this with some work. More inline; I >> will preserve the description of the problem you provided for >> context. >> >>> Now both the red and blue domains have a user called tel:1234 but we >>> don't want red tel:1234 to get IMs meant for blue. Blue sends an IM >>> to Alice at some other domain. This forms an alias to the server. >>> Now Red bob sends an IM to Alice - this updates the alias and >>> basically hijacks blue. When ALice relies to blue, the proxy in >>> Alice's domain will mistakenly select the TLS connection that was >>> formed by red domain since it goes to the correct ip address, port, >>> and transport. The virtual domain that servers red and blue will >>> process the request in the context of red since it received it over >>> a TLS connection that is part of the red domain. You might say this >>> is a corner case but hosting multiple virtual domains this way is >>> very desirable and the HTTP people have been working hard to make >>> this easier to deploy. The latest version of common TLS libraries >>> are starting to support this and I expect to see more servers that >>> can do this. (PS. I think I have mentioned this on several different >>> versions of this document - let me know if I am not making any >>> sense) >> >> In order to arrive at how to solve this, the idea from Jonathan's >> email about a server caching client certificates for later >> use come into the picture. Here are the steps: >> >> 1) We have a proxy P that has two virtual domains -- red.com >> and blue.com -- accessible at port 5061 (note that in the >> scenario we are talking about, the destination port really >> does not matter. The problem arises when P sends *out* >> requests from its respective domains to a third party, and >> that third party wants to re-use the ensuing connection for >> requests in the backwards direction). >> >> 1a) P has a physical address of 192.168.1.2. >> >> 2) red.com has a user with a URI of sip:bob@red.com. >> >> 3) blue.com has a user with a URI of sip:bob@blue.com. >> >> 4) Now, bob@blue.com sends out a request to Alice through P: >> MESSAGE sips:alice@P2.com SIP/2.0 >> From: ;tag=8uxy--y6 >> Via: SIP/2.0/TLS blue.com;branch=... >> ... >> 5) Alice's proxy (P2) gets the request and creates an alias: >> >> Dest. Dest. Dest. Dest. Alias >> Address Port Transport Certificate Descriptor >> 192.168.1.2 5061 TLS blue.com 28 >> >> Note the new column (Dest. Certificate) -- this is key to >> solving this particular problem. The certificate from >> blue.com is cached by P2, and the domain name in the column is >> got from either the Via, or better yet, from the SAN in the >> certificate. >> >> Now requests from P2 towards the blue.com:5061 domain will go through >> the alias descriptor 28, which is tied to 192.168.1.2:6666 (port >> 6666 being the source port chosen by the sending TCP). >> >> 6) At some later time, bob@red.com sends a request to Alice through >> P: >> MESSAGE sips:alice@P2.com SIP/2.0 >> From: ;tag=9j7-y6 >> Via: SIP/2.0/TLS red.com;branch=... >> ... >> >> 7) Alice's proxy (P2) gets the request and updates its alias >> table with a new row: >> >> Dest. Dest. Dest. Dest. Alias >> Address Port Transport Certificate Descriptor >> 192.168.1.2 5061 TLS blue.com 28 >> 192.168.1.2 5061 TLS red.com 32 >> >> Requests from P2 towards the red.com:5061 domain will go >> through the alias descriptor 32, which is tied to 192.168.1.2:7777 >> (port 7777 being the source port chosen by the sending TCP). >> >> 8) When P2 wants to send a request in the opposite direction, it >> will run the next hop URI through rfc3263 resolution. That >> resolution will result in an IP address/port/transport >> (192.168.1.2:5061:TLS). But instead of simply sending it to >> the first such row from the alias table, P2 will need to >> authenticate the URI used in the rfc3263 resolution to the >> appropriate certificate in order to choose the right descriptor. >> >> Thus, P knows that all requests coming in the backwards direction >> over 192.168.1.2:6666 belong to blue.com and those arriving over >> 192.168.1.2:7777 belong to red.com. >> >> I know this makes for a rather complex set of gyrations, but if >> we want to support name-based virtual servers, then this is one >> way that accounts for the requirements listed in Section 6 >> of the connect-reuse draft. If there are better and more elegant >> ways to do this, I would love to hear them. >> >> Thoughts? >> >> Thanks. >> >> - vijay >> >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 14:34:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsqq-0008At-0G; Wed, 09 Aug 2006 14:32:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsqp-00089q-Bc for sip@ietf.org; Wed, 09 Aug 2006 14:32:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAqvR-00034R-2R for sip@ietf.org; Wed, 09 Aug 2006 12:28:57 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAqgh-0007By-HD for sip@ietf.org; Wed, 09 Aug 2006 12:13:46 -0400 Received: from BPenfield [10.0.200.6] by acmepacket.com with ESMTP (SMTPD-9.03) id A9A601B8; Wed, 09 Aug 2006 12:13:26 -0400 Message-ID: <002001c6bbce$b7a4dd50$800101df@acmepacket.com> From: "Bob Penfield" To: "Hisham Khartabil" , "Rohan Mahy" References: <0590a1057c40fa96aee3d22cb551fb87@telio.no> Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 12:13:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -2.6 (--) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't think the verification should be required, I just want to have a method to verify. That way, a UA that does not have a means to learn the outbound proxy set thru auto-config or discovery mechanisms can try to use outbound w/STUN. I would make it a MAY for the UA. The procedures for handling sip-stun in Proxy-Require/Require would be required for the proxy and registrar. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Hisham Khartabil" To: "Rohan Mahy" Cc: "IETF SIP List" Sent: Wednesday, August 09, 2006 11:03 AM Subject: Re: [Sip] Outbound Issues: slides 3 and 4 >I don't like this proposal. I'm still with the camp that says: if >configured, then it must be true. > > My main objection is that in this proposal, you are required to send SIP > messages before STUN messages. That's a mandate that I'm not comfortable > with since I might want to send STUN first to discover my public IP/port > to populate the contact header before I send the first REGISTER. > > Hisham > > On Aug 8, 2006, at 4:38 PM, Rohan Mahy wrote: > >> >> We had a very long discussion in Montreal about discovery and validation >> of a SIP outbound proxy server's ability to receive STUN requests. While >> the vast majority of the room was comfortable that "keepalive=stun" in a >> URI was a sufficient indicator that an outbound proxy supports SIP and >> STUN over the same port, a small but extremely vocal minority had >> significant problems with this assumption. After a discussion with Dean, >> I am willing to try a validation proposal which adds no extra round trips >> if the SIP UA was indeed correctly configured. >> >> The specific proposal works like this. A UAC which has an outbound URI >> indicating with ;keepalive=stun that the next hop can support STUN >> messages on the SIP port, needs to verify the first hop supports STUN >> before sending any STUN messages. The UAC sends its first SIP message to >> the next hop with a Proxy-Require: sip-stun. If the URI was correct >> (STUN was supported), and the first-hop is an intermediary, the first-hop >> removes the Proxy-Require and forwards the SIP request (probably a >> REGISTER request) along adding no additional delay. A positive response >> to a REGISTER or OPTIONS with Supported: outbound and no error counts as >> positive confirmation that either the registrar supports STUN or expects >> to never receive a request without getting it from an outbound proxy >> which did not complain about the Proxy-Require [1]. If the UAC was >> misconfigured (the first-hop intermediary does not support STUN >> keepalives), either the first hop will reject the SIP request (if it is >> an intermediary), or the registrar will not include an indicator that it >> supports outbound (if the first hop was the registrar). >> >> Note that this proposal is not a full *discovery* mechanism, just a >> verification mechanism. For example, if the registrar doesn't support >> outbound, but the first-hop does, there is no way described here to >> discover that the first-hop can accept STUN keepalives. Do not confuse >> support of STUN with support of outbound. Supported: outbound implies >> that the registrar supports STUN or is configured to use an outbound >> proxy that does. The sip-stun option tag only means that you can send >> and receive STUN requests on your SIP port. While outbound requires STUN, >> STUN does not require outbound. >> >> [1] Also Note that there is a caveat that you can still shoot yourself in >> the foot if you allow messages to come straight to your registrar that >> does not support STUN. I think we agreed that we are not going to >> enumerate all the ways you can subtly break things in SIP though. >> >> thanks, >> -rohan >> >> >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 14:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt7e-0001sy-VN; Wed, 09 Aug 2006 14:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt7c-0001st-Jf for sip@ietf.org; Wed, 09 Aug 2006 14:49:40 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAt7b-0004ot-8v for sip@ietf.org; Wed, 09 Aug 2006 14:49:40 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2006 11:49:39 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="310742248:sNHT26742420" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79Incdo023312; Wed, 9 Aug 2006 11:49:38 -0700 Received: from [192.168.1.2] (sjc-vpn4-506.cisco.com [10.21.81.250]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79In6Ia000601; Wed, 9 Aug 2006 11:49:38 -0700 (PDT) In-Reply-To: <6c91a88d048a5acea156de16a7f4fe44@ekabal.com> References: <6c91a88d048a5acea156de16a7f4fe44@ekabal.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <763778FF-2201-4E34-A30A-218ACEB830EF@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound issues: slides 9 and 10 Date: Wed, 9 Aug 2006 11:49:35 -0700 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2574; t=1155149378; x=1156013378; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20issues=3A=20slides=209=20and=2010=20; X=v=3Dcisco.com=3B=20h=3D6sgeqApyTnkRrddZfg8x2siO+JE=3D; b=GOLYRiuJ4zTA1afEuPdvnAGSwDtf+9IKCWUmH9DVTBtpVP0AbvzoQHuOhrg+ceGr5rIasGL9 /jXmHZ0yidG9uuM1E9vTtxkwZTaoPna99CEfv+BjboEhYopitz0BdXPI; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think we need to work on this proposal before I really understand where it is needed and what it protects from. What happens if the proxy does not insert a flow token? What proxies are in a foreign domain and why do how do they handle things that differently than one that is not. This would break some of the proposal for high reliability. I think the authors should get together and come up with a proposal for what we are talking about here. On Aug 8, 2006, at 7:38 AM, Rohan Mahy wrote: > The issues on slide 9 (how does a registrar verify that an edge > proxy supports outbound) and slide 10 (what does "Supported: > outbound" mean) deal with detecting that all the required hops > support outbound. Slide 9 specifically uncovered a problem with > outbound proxies that add a Path URI but don't include a flow token. > > The proposed solution is as follows. If a proxy inserts a Path > header with a flow token consistent with the rules described in > outbound, it MUST add the ;ob parameter to the proxy URI that has > the flow token. > > The registrar verifies that any Path header URIs contain the ;ob > parameter. If there are any Path URIs without the ob parameter, > the registrar does not rFrom sip-bounces@ietf.org Wed Aug 09 14:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt7e-0001sy-VN; Wed, 09 Aug 2006 14:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt7c-0001st-Jf for sip@ietf.org; Wed, 09 Aug 2006 14:49:40 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAt7b-0004ot-8v for sip@ietf.org; Wed, 09 Aug 2006 14:49:40 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2006 11:49:39 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="310742248:sNHT26742420" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79Incdo023312; Wed, 9 Aug 2006 11:49:38 -0700 Received: from [192.168.1.2] (sjc-vpn4-506.cisco.com [10.21.81.250]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79In6Ia000601; Wed, 9 Aug 2006 11:49:38 -0700 (PDT) In-Reply-To: <6c91a88d048a5acea156de16a7f4fe44@ekabal.com> References: <6c91a88d048a5acea156de16a7f4fe44@ekabal.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <763778FF-2201-4E34-A30A-218ACEB830EF@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound issues: slides 9 and 10 Date: Wed, 9 Aug 2006 11:49:35 -0700 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2574; t=1155149378; x=1156013378; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20issues=3A=20slides=209=20and=2010=20; X=v=3Dcisco.com=3B=20h=3D6sgeqApyTnkRrddZfg8x2siO+JE=3D; b=GOLYRiuJ4zTA1afEuPdvnAGSwDtf+9IKCWUmH9DVTBtpVP0AbvzoQHuOhrg+ceGr5rIasGL9 /jXmHZ0yidG9uuM1E9vTtxkwZTaoPna99CEfv+BjboEhYopitz0BdXPI; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think we need to work on this proposal before I really understand where it is needed and what it protects from. What happens if the proxy does not insert a flow token? What proxies are in a foreign domain and why do how do they handle things that differently than one that is not. This would break some of the proposal for high reliability. I think the authors should get together and come up with a proposal for what we are talking about here. On Aug 8, 2006, at 7:38 AM, Rohan Mahy wrote: > The issues on slide 9 (how does a registrar verify that an edge > proxy supports outbound) and slide 10 (what does "Supported: > outbound" mean) deal with detecting that all the required hops > support outbound. Slide 9 specifically uncovered a problem with > outbound proxies that add a Path URI but don't include a flow token. > > The proposed solution is as follows. If a proxy inserts a Path > header with a flow token consistent with the rules described in > outbound, it MUST add the ;ob parameter to the proxy URI that has > the flow token. > > The registrar verifies that any Path header URIs contain the ;ob > parameter. If there are any Path URIs without the ob parameter, > the registrar does not return Supported: outbound. Furthermore, > the registrar needs to check that the first hop after the UAC is > represented in the Path list (unless the registrar recognizes that > the first hop after the UAC is in the same domain and doesn't need > to include Path URIs with a flow token). Note that this implies > that whatever the proxy puts in the Via (IP address or FQDN), it > must put the same hostname in the Path header (but there is no need > for a complete URI comparison). If the first hop is not correctly > represented, the registrar ignores the reg-id parameter and does > not return Supported: outbound. > > The implication of this is that an outbound-proxy that supports > outbound needs to support Path and flow tokens for registrations to > all foreign domains. Inside the same domain, the first-hop proxy > and the registrar can still use Path to communicate with each > other, but they can use some other private mechanism to > disaggregate this functionality. > > thanks, > -rohan > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 14:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt7m-0001ts-O7; Wed, 09 Aug 2006 14:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt7l-0001tn-Pu for sip@ietf.org; Wed, 09 Aug 2006 14:49:49 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAt7k-0004rR-8I for sip@ietf.org; Wed, 09 Aug 2006 14:49:49 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Aug 2006 11:49:48 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="1845646842:sNHT27187524" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79InlJ0026260; Wed, 9 Aug 2006 11:49:47 -0700 Received: from [192.168.1.2] (sjc-vpn4-506.cisco.com [10.21.81.250]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79In6Ib000601; Wed, 9 Aug 2006 11:49:47 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ... Date: Wed, 9 Aug 2006 11:49:45 -0700 To: IETF SIP List X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2453; t=1155149387; x=1156013387; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20=20-=20the =20problem=20...; X=v=3Dcisco.com=3B=20h=3DXGT2dZCkxDdI86zXSNI6kk3j5xw=3D; b=TQ3FIcr0veXU3EBJ6bhs3iSMayADsj6x+UF7gK/53f7dHBNku7IaDtN7i4bVTujIge/kymQv Gd+opbPWl29kuoa8csR3AgxkIAn7gQI6CqvzTDE9AG6DDHBEFMd+JmBq; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Rohan Mahy X-BeenThere: eturn Supported: outbound. Furthermore, > the registrar needs to check that the first hop after the UAC is > represented in the Path list (unless the registrar recognizes that > the first hop after the UAC is in the same domain and doesn't need > to include Path URIs with a flow token). Note that this implies > that whatever the proxy puts in the Via (IP address or FQDN), it > must put the same hostname in the Path header (but there is no need > for a complete URI comparison). If the first hop is not correctly > represented, the registrar ignores the reg-id parameter and does > not return Supported: outbound. > > The implication of this is that an outbound-proxy that supports > outbound needs to support Path and flow tokens for registrations to > all foreign domains. Inside the same domain, the first-hop proxy > and the registrar can still use Path to communicate with each > other, but they can use some other private mechanism to > disaggregate this functionality. > > thanks, > -rohan > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 14:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt7m-0001ts-O7; Wed, 09 Aug 2006 14:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt7l-0001tn-Pu for sip@ietf.org; Wed, 09 Aug 2006 14:49:49 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAt7k-0004rR-8I for sip@ietf.org; Wed, 09 Aug 2006 14:49:49 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Aug 2006 11:49:48 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="1845646842:sNHT27187524" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79InlJ0026260; Wed, 9 Aug 2006 11:49:47 -0700 Received: from [192.168.1.2] (sjc-vpn4-506.cisco.com [10.21.81.250]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79In6Ib000601; Wed, 9 Aug 2006 11:49:47 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ... Date: Wed, 9 Aug 2006 11:49:45 -0700 To: IETF SIP List X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2453; t=1155149387; x=1156013387; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20=20-=20the =20problem=20...; X=v=3Dcisco.com=3B=20h=3DXGT2dZCkxDdI86zXSNI6kk3j5xw=3D; b=TQ3FIcr0veXU3EBJ6bhs3iSMayADsj6x+UF7gK/53f7dHBNku7IaDtN7i4bVTujIge/kymQv Gd+opbPWl29kuoa8csR3AgxkIAn7gQI6CqvzTDE9AG6DDHBEFMd+JmBq; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 8, 2006, at 7:38 AM, Rohan Mahy wrote: > > We had a very long discussion in Montreal about discovery and > validation of a SIP outbound proxy server's ability to receive STUN > requests. While the vast majority of the room was comfortable that > "keepalive=stun" in a URI was a sufficient indicator that an > outbound proxy supports SIP and STUN over the same port, a small > but extremely vocal minority had significant problems with this > assumption. Just so we are clear on the when this could be a problem.... For any UA that is automatically configured, this is unlikely to every be a problem. What we are talking about here is UA where some human types in the configuration information to the UA. Even though they were told to enter example.com as the outbound proxy, they decide to enter example.com;keep-alice=stun because perhaps they saw that in some other system. Their device sends a stun packet and gets black listed. Note that any services that blacklists after receiving a single STUN packet with a spoofed IP address is going to be trivial to totally DOS so I don't believe this sort of thing will deploy buts let continue down this case. So the user UA does not work. It also would not have worked if they typed in elpmaxe.com (example backwards). What do they do? read a web page, phone tech support, I have no idea but they do whatever they do when they configure the outbound proxy information correction. Eventually they find out to remove the keep-alive=stun and their phone starts working. For these reasons, I don't think this whole problem is not a huge deal. However, if people do think it is a big deal, the obvious solution to it is send and OPTIONS message to find out if the server supports this. Most people don't seem to think this is enough of a problem to warrant and additional RTT when a UA boots. We can come up with other possible solutions to this too (as there are at least three others on this same thread). The meta question is simple - we had pretty strong consensus on this in the meeting. How long do we really want to spend delaying this draft to find alternative solutions to this problem. Clearly the answer different based on how serious a problem you think it is. It would be really great if the authors, chairs, and people that feel strongly could have a conference call on this. _______________________________________________ Sip mailing list https://www1.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@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 8, 2006, at 7:38 AM, Rohan Mahy wrote: > > We had a very long discussion in Montreal about discovery and > validation of a SIP outbound proxy server's ability to receive STUN > requests. While the vast majority of the room was comfortable that > "keepalive=stun" in a URI was a sufficient indicator that an > outbound proxy supports SIP and STUN over the same port, a small > but extremely vocal minority had significant problems with this > assumption. Just so we are clear on the when this could be a problem.... For any UA that is automatically configured, this is unlikely to every be a problem. What we are talking about here is UA where some human types in the configuration information to the UA. Even though they were told to enter example.com as the outbound proxy, they decide to enter example.com;keep-alice=stun because perhaps they saw that in some other system. Their device sends a stun packet and gets black listed. Note that any services that blacklists after receiving a single STUN packet with a spoofed IP address is going to be trivial to totally DOS so I don't believe this sort of thing will deploy buts let continue down this case. So the user UA does not work. It also would not have worked if they typed in elpmaxe.com (example backwards). What do they do? read a web page, phone tech support, I have no idea but they do whatever they do when they configure the outbound proxy information correction. Eventually they find out to remove the keep-alive=stun and their phone starts working. For these reasons, I don't think this whole problem is not a huge deal. However, if people do think it is a big deal, the obvious solution to it is send and OPTIONS message to find out if the server supports this. Most people don't seem to think this is enough of a problem to warrant and additional RTT when a UA boots. We can come up with other possible solutions to this too (as there are at least three others on this same thread). The meta question is simple - we had pretty strong consensus on this in the meeting. How long do we really want to spend delaying this draft to find alternative solutions to this problem. Clearly the answer different based on how serious a problem you think it is. It would be really great if the authors, chairs, and people that feel strongly could have a conference call on this. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 14:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt86-0002Lc-BM; Wed, 09 Aug 2006 14:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt85-0002LK-61 for sip@ietf.org; Wed, 09 Aug 2006 14:50:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAt82-0004sm-RH for sip@ietf.org; Wed, 09 Aug 2006 14:50:09 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2006 11:50:06 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="310742421:sNHT578723000" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79Io5rs023730; Wed, 9 Aug 2006 11:50:05 -0700 Received: from [192.168.1.2] (sjc-vpn4-506.cisco.com [10.21.81.250]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79In6Ic000601; Wed, 9 Aug 2006 11:50:05 -0700 (PDT) In-Reply-To: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> References: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 11:50:03 -0700 To: Dean Willis X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=3170; t=1155149405; x=1156013405; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=W8gNGwPpYe7IByoxhWyeId/iSIcYnEov/xJf57VeWefGzArP0aua/9pIIJawXJdOZdxTMSVQ i99lO18p/pJ6W8OKLLUbfQBaVUDPqk3cBPNWNVx8Jy7PICRWYW92cXes; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Adding a bit more at bottom... On Aug 8, 2006, at 1:02 PM, Dean Willis wrote: > > On Aug 8, 2006, at 9:38 AM, Rohan Mahy wrote: > >> >> The specific proposal works like this. A UAC which has an >> outbound URI indicating with ;keepalive=stun that the next hop can >> support STUN messages on the SIP port, needs to verify the first >> hop supports STUN before sending any STUN messages. The UAC sends >> its first SIP message to the next hop with a Proxy-Require: sip- >> stun. If the URI was correct (STUN was supported), and the first- >> hop is an intermediary, the first-hop removes the Proxy-Require >> and forwards the SIP request (probably a REGISTER request) along >> adding no additional delay. A positive response to a REGISTER or >> OPTIONS with Supported: outbound and no error counts as positive >> confirmation that either the registrar supports STUN or expects to >> never receive a request without getting it from an outbound proxy >> which did not complain about the Proxy-Require [1]. If the UAC was >> misconfigured (the first-hop intermediary does not support STUN >> keepalives), either the first hop will reject the SIP request (if >> it is an intermediary), or the registrar will not include an >> indicator that it supports outbound (if the first hop was the >> registrar). >> > > Cullen suggested an alternate possibility that might work. > > I'll try and paraphrase: > > A UAC which has an outbound URI indicating with ;keepalive=stun > that the next hop can support STUN messages on the SIP port needs > to verify the first hop supports STUN before repeatedly sending > STUN messages. The UAC may initially try sending STUN messages to > the SIP port of the first hop node. If the UAC does not receive a > correct STUN response (within some timer?) then it must assume > that this mode does not support STUN, and proceed without using > STUN until it has some evidence that the first-hop node might have > changed, in which case it retries the STUN requests as per the > initial attempt. > > I think it's probably okay to stun a server a few times before > deciding it doesn't like being stunned -- after all, the primary > risk is one of slowing down service for the user doing the > stunning, not shutting down the server being stunned. What I object > to is a specification that says you go on stunning it indefinitely, > perhaps millions of times over the course of an association, with > no way to discover that you really shouldn't be stunning it. > > Set phasers on "stun", Mr. Sulu! > > -- > Dean What I was trying to accomplish here was a solution that: 1) you don't send a STUN request until you receive a successful response to the register, this lets you know the device you are about to send a stun request to is "up" 2) you send a small number of stun requests and if you don't get any response, then you conclude that the server does not support stun and you stop stunning it As I mention on another email in this thread, I don't think it will be practical to blacklist an IP after a single stun packet so I think this solution could probably work. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 14:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt8z-0002wf-0K; Wed, 09 Aug 2006 14:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt8x-0002wa-QH for sip@ietf.org; Wed, 09 Aug 2006 14:51:03 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAt8w-0005AA-GQ for sip@ietf.org; Wed, 09 Aug 2006 14:51:03 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Aug 2006 11:51:02 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="1845647416:sNHT26777136" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79Ip1S4027122; Wed, 9 Aug 2006 11:51:01 -0700 Received: from [192.168.1.2] (sjc-vpn4-506.cisco.com [10.21.81.250]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79In6Id000601; Wed, 9 Aug 2006 11:50:52 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <378641DE-FA7A-46E5-AE73-5954DF271BD4@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - B2BUA Proposal Date: Wed, 9 Aug 2006 11:50:44 -0700 To: IETF SIP List X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2481; t=1155149461; x=1156013461; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20-=20B2BUA= 20Proposal; X=v=3Dcisco.com=3B=20h=3DOsIsa9l+QTO3JmDtPMXkIwT3SBw=3D; b=PlBKN9eQW3rO8ufvNIGErrEsnWjItd1jK+DYavvXmTBkllIxWHFsnVhcVkszcCGkfPDXL/ZZ pEEkA0uuXCLbaC4HpEqcqI/+AFfG/GZ0+OE2hnqPH4CK7aXOJxIUURLC; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > The specific proposal works like this. A UAC which has an outbound > URI indicating with ;keepalive=stun that the next hop can support > STUN messages on the SIP port, needs to verify the first hop > supports STUN before sending any STUN messages. The UAC sends its > first SIP message to the next hop with a Proxy-Require: sip-stun. > If the URI was correct (STUN was supported), and the first-hop is > an intermediary, the first-hop removes the Proxy-Require and > forwards the SIP request (probably a REGISTER request) along adding > no additional delay. A positive response to a REGISTER or OPTIONS > with Supported: outbound and no error counts as positive > confirmation that either the registrar supports STUN or expects to > never receive a request without getting it from an outbound proxy > which did not complain about the Proxy-Require [1]. If the UAC was > misconfigured (the first-hop intermediary does not support STUN > keepalives), either the first hop will reject the SIP request (if > it is an intermediary), or the registrar will not include an > indicator that it supports outbound (if the first hop was the > registrar). If I am reading 3261 correctly, the proxy would no longer be a proxy but a B2BUA. I had proposed this a long time ago and several people were very concerned about proxies modifying Proxy-Require headers. By the time they were done with me, I shared their concerns about doing that. This is a very slippery slope to be diving down if we ever expect to have some level of integrity around the only mechanism available in SIP for negotiation future forward compatibility with proxies. It would likely work with stuff that is deployed today but it is not backwards compatible with things we have specified today. An UAS that did AIB would be perfectly correct to reject a response that had proxy required where things had been removed. People bring up some of the 3G security stuff as a example that this is ok - but that was something that was intended for a specific and high controlled deployment model. It was also something that has had some difficulties so I would hardly use it as an example of why this is all alright. As EKR would say, the important high oder bit here is, regardless of if we end up rewriting 3261 to make this change or not, the discussion to make the decision is probably not going to be short. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 14:58:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtEg-0007BV-IE; Wed, 09 Aug 2006 14:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtEe-0007Az-La for sip@ietf.org; Wed, 09 Aug 2006 14:56:56 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtEd-0005Xa-1D for sip@ietf.org; Wed, 09 Aug 2006 14:56:56 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Aug 2006 11:56:34 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="1845649805:sNHT2253391228" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79IuYqS031874; Wed, 9 Aug 2006 11:56:34 -0700 Received: from [192.168.1.2] (sjc-vpn4-506.cisco.com [10.21.81.250]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k79IuTuD009965; Wed, 9 Aug 2006 11:56:29 -0700 (PDT) In-Reply-To: <002001c6bbce$b7a4dd50$800101df@acmepacket.com> References: <0590a1057c40fa96aee3d22cb551fb87@telio.no> <002001c6bbce$b7a4dd50$800101df@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05D38DF0-A29A-42DB-B059-326A788FE576@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 11:56:22 -0700 To: Bob Penfield X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1022; t=1155149794; x=1156013794; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=zKvIcPlYjXtQjZNzVpQRIKBH9KRy/ssDHJ6Z940vvEurh3+vvM9jfxWN7FvN2EZFl0bnhYjY WaK5CuTv/T1Bldq+xQ86IPgfGEZzdVU6V3MRKaWK/uvoTulLAH0PKDDN; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Bob, How about if we said something like If the UA did not learn the outbound proxy set thru auto-config or discovery mechanisms, then it MUST do an OPTIONS message first and check for a sip-stun option tag. (clearly more wording needed but you know what I mean) Would that work for you? I suspect it would work for most people. I'd certainly be in favor of that. I suspect for proxies with millions of users, they will use auto-config so this will not slow them down and for proxies with UA with manual config, it will not be enough UA to cause a huge performance impact. I don't know why I did not think of this before. Cullen On Aug 9, 2006, at 9:13 AM, Bob Penfield wrote: > I don't think the verification should be required, I just want to > have a method to verify. That way, a UA that does not have a means > to learn the outbound proxy set thru auto-config or discovery > mechanisms can try to use outbound w/STUN. I would make it a MAY > for the UA. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 14:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtEx-00080W-Ip; Wed, 09 Aug 2006 14:57:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtEv-0007xW-JZ for sip@ietf.org; Wed, 09 Aug 2006 14:57:13 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtEt-0005YZ-RD for sip@ietf.org; Wed, 09 Aug 2006 14:57:13 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9C8D26E0001; Wed, 9 Aug 2006 20:57:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 20:57:10 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 20:57:10 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 20:57:09 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12FA@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca75KWTP4W8jyawS0uxQoeooK9WfwAAHkvA From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 09 Aug 2006 18:57:10.0061 (UTC) FILETIME=[9E1355D0:01C6BBE5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Cullen suggested an alternate possibility that might work. >> >>I'll try and paraphrase: >> >>A UAC which has an outbound URI indicating with ;keepalive=3Dstun that = >>the next hop can support STUN messages on the SIP port needs to verify >>the first hop supports STUN before repeatedly sending STUN messages. =20 >>The UAC may initially try sending STUN messages to the SIP port of the >>first hop node. If the UAC does not receive a correct STUN response=20 >>(within some timer?) then it must assume that this mode does not=20 >>support STUN, and proceed without using STUN until it has some=20 >>evidence that the first-hop node might have changed, in which case it=20 >>retries the STUN requests as per the initial attempt. >> >>I think it's probably okay to stun a server a few times before=20 >>deciding it doesn't like being stunned -- after all, the primary risk=20 >>is one of slowing down service for the user doing the stunning, not=20 >>shutting down the server being stunned. What I object to is a=20 >>specification that says you go on stunning it indefinitely, perhaps=20 >>millions of times over the course of an association, with no way to=20 >>discover that you really shouldn't be stunning it. >> >>Set phasers on "stun", Mr. Sulu! >> >>-- >>Dean >What I was trying to accomplish here was a solution that: > >1) you don't send a STUN request until you receive a successful response to the register, this lets you know the device=20 >you are about to send a stun request to is "up" > >2) you send a small number of stun requests and if you don't get any response, then you conclude that the server does not=20 >support stun and you stop stunning it > >As I mention on another email in this thread, I don't think it will be practical to blacklist an IP after a single stun=20 >packet so I think this solution could probably work. Why can't the proxy, if it inserts a Path header, add keepalive=3Dstun = to that Path header? Then the UAC does not need to send stun request in order to figure out whether the proxy supports STUN keepalive or not. (Of course, if the proxy does NOT support Path then the UAC may have to figure out by sending STUN requests.) Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 15:23:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtcI-00055K-A3; Wed, 09 Aug 2006 15:21:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtcG-00052m-QW for sip@ietf.org; Wed, 09 Aug 2006 15:21:20 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtRX-0006vb-Jx for sip@ietf.org; Wed, 09 Aug 2006 15:10:16 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k79JAEqq002119; Wed, 9 Aug 2006 14:10:14 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k79JAEu13190; Wed, 9 Aug 2006 14:10:14 -0500 (CDT) Message-ID: <44DA3316.3000504@lucent.com> Date: Wed, 09 Aug 2006 14:10:14 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] comments on draft-ietf-sip-connect-reuse-05 References: <44ADE168.7050309@cisco.com> <44AF59A8.1000304@lucent.com> <77482B40-90DF-43A7-BC76-07EA1AF05C52@cisco.com> <44D90A7D.1030303@lucent.com> <28C1FAA8-8E9A-42C0-9C44-DF771089F110@cisco.com> In-Reply-To: <28C1FAA8-8E9A-42C0-9C44-DF771089F110@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > Yes - this solves it. The key thing is the table has to store the > name (or names) from the TLS cert and that when you go to reuse the > connection, you can only reuse it if the target you are sending to > if it matches this name from the cert. Yes. > Now, assuming we did this, it brings up some other questions which I > don't really feel that strongly about - [...] > I'm ok with the draft going any one of the following direction on > this 1) always do all the DNS stuff resulting in O(n^2) connection > between two farms that both had n proxies 2) don't keep the IP and > port in the table resulting in O(n) connection between two farms > that both had n proxies 3) let it be an configurable option. My preference is (1) since it does not disrupt SRV load balancing. After all the rfc3263 gyrations, you will always end up with an {IP address, port, transport} tuple. And if you have that information saved already, you can always avail of it to make an intelligent decision. If the WG prefers, it can be mentioned in the draft that (2) is an option as well, and allow implementations to choose it with appropriate caveats. > No matter what way we go, your proposal here solves the security > problem and I like it. OK. I will put this into the draft. Thanks for your time in a quick turnaround. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 15:23:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtcG-00052n-SK; Wed, 09 Aug 2006 15:21:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtcE-00050b-GN for sip@ietf.org; Wed, 09 Aug 2006 15:21:18 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtRf-0006x9-81 for sip@ietf.org; Wed, 09 Aug 2006 15:10:24 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k79JAHGo002176; Wed, 9 Aug 2006 14:10:17 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k79JAHu13238; Wed, 9 Aug 2006 14:10:17 -0500 (CDT) Message-ID: <44DA3319.5080905@lucent.com> Date: Wed, 09 Aug 2006 14:10:17 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] comments on draft-ietf-sip-connect-reuse-05 References: <44ADE168.7050309@cisco.com> <44AF59A8.1000304@lucent.com> <77482B40-90DF-43A7-BC76-07EA1AF05C52@cisco.com> <44D90A7D.1030303@lucent.com> <28C1FAA8-8E9A-42C0-9C44-DF771089F110@cisco.com> <44DA268E.5020209@cisco.com> In-Reply-To: <44DA268E.5020209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > I am confused by Vijay's example because it shows the entries for > red.com and blue.com being established independently. They have the same > address and port, and it isn't clear if they share a connection. No, they don't share a connection; that is, red.com and P2 share a connection that is distinct from the one shared by blue.com and P2. Yes, the address and port for red.com and blue.com are the same in P2's table (because it is the same physical server, albeit with multiple personalities), but think of these as an index that P2 uses to see if it has an existing connection already open to a certain IP address/port/transport tuple (resulting from an rfc3263-lookup on a URI). If it does, then an additional check for a cached cert would be done. > I would think that Bob's proxy would only establish one connection to > Alice's proxy, and that the TLS handshake would provide all the > identities that Bob's proxy has. (red.com and blue.com) No; it should be one certificate per virtual domain. When P (Bob's proxy) makes a connection to P2, it can have policies on which certificate to present to P2, if asked. In the same vein that using TLS extended hello, a client can ask the server for a certificate corresponding to a particular domain. Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 15:23:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtcO-0005Kc-DM; Wed, 09 Aug 2006 15:21:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtcM-0005Cm-4q for sip@ietf.org; Wed, 09 Aug 2006 15:21:26 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtPH-0006pn-2Q for sip@ietf.org; Wed, 09 Aug 2006 15:07:56 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 71A936E0002; Wed, 9 Aug 2006 21:07:54 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 21:07:54 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 21:07:53 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 - the problem ... Date: Wed, 9 Aug 2006 21:07:53 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12FB@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 - the problem ... Thread-Index: Aca75J4+IP+zyVilQluuyaMAJk5d3wAAXbJg From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "IETF SIP List" X-OriginalArrivalTime: 09 Aug 2006 19:07:53.0841 (UTC) FILETIME=[1DCC5E10:01C6BBE7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>We had a very long discussion in Montreal about discovery and=20 >>validation of a SIP outbound proxy server's ability to receive STUN=20 >>requests. While the vast majority of the room was comfortable that=20 >>"keepalive=3Dstun" in a URI was a sufficient indicator that an = outbound=20 >>proxy supports SIP and STUN over the same port, a small but extremely=20 >>vocal minority had significant problems with this assumption. >> >>Just so we are clear on the when this could be a problem.... >> >For any UA that is automatically configured, this is unlikely to every be a problem.=20 Assuming the UA is configured with a URI, yes. But, in case the UA only gets the IP address of the proxy, you still have a problem. Because, EVEN if you require configured URIs with outbound, you can use STUN keepalive without outbound. >What we are talking about here is UA where some human types in the configuration information to the UA. Even though they=20 >were told to enter example.com as the outbound proxy, they decide to enter example.com;keep-alice=3Dstun because perhaps=20 >they saw that in some other system. Their device sends a stun packet and gets black listed. Note that any services that=20 >blacklists after receiving a single STUN packet with a spoofed IP address is going to be trivial to totally DOS so I=20 >don't believe this sort of thing will deploy buts let continue down this case. So the user UA does not work. It also=20 >would not have worked if they typed in elpmaxe.com (example backwards). What do they do? read a web page, phone tech=20 >support, I have no idea but they do whatever they do when they configure the outbound proxy information correction.=20 >Eventually they find out to remove the keep-alive=3Dstun and their = phone starts working. > >For these reasons, I don't think this whole problem is not a huge deal. However, if people do think it is a big deal, the=20 >obvious solution to it is send and OPTIONS message to find out if the server supports this. If you want to know before you send the REGISTER request, you can do that. But, again, I think the outbound proxy should be able to indicate the support, e.g. by inserting keepalive=3Dstun in the Path header.=20 >Most people don't seem to think this is enough of a problem to warrant and additional RTT when a UA boots. We can come up=20 >with other possible solutions to this too (as there are at least three others on this same thread). > >The meta question is simple - we had pretty strong consensus on this in the meeting. How long do we really want to spend=20 >delaying this draft to find alternative solutions to this problem. Clearly the answer different based on how serious a=20 >problem you think it is. I have presented an alternative solution :) If it doesn't work, fine, but as far as I remember nobody has yet told me it doesn't work. Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 15:23:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtcQ-0005U7-Pl; Wed, 09 Aug 2006 15:21:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtcN-0005HN-C4 for sip@ietf.org; Wed, 09 Aug 2006 15:21:27 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtO7-0006f6-6u for sip@ietf.org; Wed, 09 Aug 2006 15:06:44 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 47FA83BECE; Wed, 9 Aug 2006 21:06:42 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09689-01-12; Wed, 9 Aug 2006 21:06:41 +0200 (CEST) Received: from [192.168.123.15] (c-affae055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.250.175]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 913F13BE51; Wed, 9 Aug 2006 21:06:41 +0200 (CEST) From: Fredrik Thulin To: "Hadriel Kaplan" Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 21:05:14 +0200 User-Agent: KMail/1.9.3 References: <00a801c6bbde$ddffa3d0$b7c8000a@acmepacket.com> In-Reply-To: <00a801c6bbde$ddffa3d0$b7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608092105.14347.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.546 tagged_above=-99 required=7 tests=[AWL=0.119, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, 'Rohan Mahy' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wednesday 09 August 2006 20:08, Hadriel Kaplan wrote: ... > > The argument that a response containing something saying "I claim I > > can handle STUN requests you send me" is to be trusted, but > > configuration saying ";keepalive=stun" is not is flawed. > > Au contraire. I would argue fairly vehemently that a server > explicitly indicating it supports something is far more reliable than > a UA believing the server supports something based on a local config > setting. The former is an explicit indication by the guy who's > responsible for doing that mechanism, whether he can do it or not; > the latter is a guess by the client as to the other side's > capabilities. Certainly the proxy can be wrong, but that probability > is miniscule to the odds that one UA out of a large population will > be wrong. UAs won't just dream up the ";keepalive=stun" - that would typically come from provisioning which is done by people who the proxy operator will have to talk to anyways. Either way, the UAC's will _have to test_ if the proxy supports sip-stun or not. > > The UA will still have to > > send a STUN request, and might or might not receive a response. > > It sure will. But if the proxy indicated support for sip-stun, that > failure would only occur if the proxy implementation was broken. ... and ";keepalive=stun" would only fail if the provisioning was broken. The ONLY thing that will NEVER fail is testing before believing. Provisioned information indicating the server supports sip-stun is definitely a strong enough indication for the UAC to send a STUN request and see, IMO. (by the way, I'm not going to say the same thing again in a subsequent e-mail, this topic seems to have a built in merry-go-round). /Fredrik _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 15:50:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAu2X-0004il-Co; Wed, 09 Aug 2006 15:48:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAu2W-0004hw-8Y for sip@ietf.org; Wed, 09 Aug 2006 15:48:28 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtth-00016F-WB for sip@ietf.org; Wed, 09 Aug 2006 15:39:23 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 25B296E0002; Wed, 9 Aug 2006 21:39:21 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 21:39:20 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 21:39: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 21:39:19 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12FE@esealmw113.eemea.ericsson.se> In-Reply-To: <200608092105.14347.ft@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca76Q2Lbp3O6VJBSwKnLOlG/g4jTwAAeE9g From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" , "Hadriel Kaplan" X-OriginalArrivalTime: 09 Aug 2006 19:39:20.0515 (UTC) FILETIME=[8257F930:01C6BBEB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org, Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>The argument that a response containing something saying "I claim I=20 >>can handle STUN requests you send me" is to be trusted, but=20 >>configuration saying ";keepalive=3Dstun" is not is flawed. >> >>Au contraire. I would argue fairly vehemently that a server=20 >>explicitly indicating it supports something is far more reliable than=20 >>a UA believing the server supports something based on a local config=20 >>setting. The former is an explicit indication by the guy who's=20 >>responsible for doing that mechanism, whether he can do it or not; the >>latter is a guess by the client as to the other side's capabilities. =20 >>Certainly the proxy can be wrong, but that probability is miniscule to >>the odds that one UA out of a large population will be wrong. >> >UAs won't just dream up the ";keepalive=3Dstun" - that would typically come from provisioning which is done by people who=20 >the proxy operator will have to talk to anyways. If you are possible to provision that information, which may not always be the case. >Either way, the UAC's will _have to test_ if the proxy supports sip-stun or not. I think it's bad design if you need to send messages in order to find out if the receiver supports the protocol in the first place... Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 16:09:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuLS-000331-Gy; Wed, 09 Aug 2006 16:08:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuLR-0002yK-0c for sip@ietf.org; Wed, 09 Aug 2006 16:08:01 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAuFx-0006kB-1o for sip@ietf.org; Wed, 09 Aug 2006 16:02:22 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-3.cisco.com with ESMTP; 09 Aug 2006 13:02:20 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="439774085:sNHT1170795302" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79K2JWv014946; Wed, 9 Aug 2006 13:02:19 -0700 Received: from [192.168.1.2] (sjc-vpn4-138.cisco.com [10.21.80.138]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79K2JIZ002096; Wed, 9 Aug 2006 13:02:19 -0700 (PDT) In-Reply-To: <05D38DF0-A29A-42DB-B059-326A788FE576@cisco.com> References: <0590a1057c40fa96aee3d22cb551fb87@telio.no> <002001c6bbce$b7a4dd50$800101df@acmepacket.com> <05D38DF0-A29A-42DB-B059-326A788FE576@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4BFE85D7-37E6-422B-B07C-C41AF0747E99@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 13:02:11 -0700 To: IETF SIP List , Bob Penfield X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1283; t=1155153739; x=1156017739; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=YGTIlMu16EeFgf1y6IyMecXFhjO/rcCL8q5gSXV3xLVFI30ucdl7ykTBGBEjcSc1+159OqcQ rcUcKccqpd3aNdOqNjxRettaCRHc3ss0QCROyRbmuULqoMzHjrrzcZTk; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 11:56 AM, Cullen Jennings wrote: > > Hi Bob, > > How about if we said something like > > If the UA did not learn the outbound proxy set thru auto-config or > discovery mechanisms, then it MUST do an OPTIONS message first and > check for a sip-stun option tag. (clearly more wording needed but > you know what I mean) > Just to update this slightly, the UA would *also* do the OPTIONS test if the auto-config of discovered proxy was only an IP address and not an URI > Would that work for you? I suspect it would work for most people. > I'd certainly be in favor of that. I suspect for proxies with > millions of users, they will use auto-config so this will not slow > them down and for proxies with UA with manual config, it will not > be enough UA to cause a huge performance impact. I don't know why I > did not think of this before. > > Cullen > > > On Aug 9, 2006, at 9:13 AM, Bob Penfield wrote: > >> I don't think the verification should be required, I just want to >> have a method to verify. That way, a UA that does not have a means >> to learn the outbound proxy set thru auto-config or discovery >> mechanisms can try to use outbound w/STUN. I would make it a MAY >> for the UA. > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 16:10:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuLl-0003jD-JJ; Wed, 09 Aug 2006 16:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuLj-0003eO-EV for sip@ietf.org; Wed, 09 Aug 2006 16:08:19 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAuAf-0005PR-8m for sip@ietf.org; Wed, 09 Aug 2006 15:56:54 -0400 Received: from BPenfield [10.0.200.6] by acmepacket.com with ESMTP (SMTPD-9.03) id ADFA03CC; Wed, 09 Aug 2006 15:56:42 -0400 Message-ID: <012701c6bbed$eece5260$800101df@acmepacket.com> From: "Bob Penfield" To: "Cullen Jennings" , "IETF SIP List" References: <378641DE-FA7A-46E5-AE73-5954DF271BD4@cisco.com> Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - B2BUA Proposal Date: Wed, 9 Aug 2006 15:56:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline ----- Original Message ----- From: "Cullen Jennings" Sent: Wednesday, August 09, 2006 2:50 PM Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - B2BUA Proposal >> > If I am reading 3261 correctly, the proxy would no longer be > a proxy but a B2BUA. I had proposed this a long time ago and several > people were very concerned about proxies > modifying Proxy-Require headers. By the time they were > done with me, I shared their concerns about doing that. > This is a very slippery slope to be diving down if we > ever expect to have some level of integrity around the > only mechanism available in SIP for negotiation future > forward compatibility with proxies. It would likely > work with stuff that is deployed today but it is not > backwards compatible with things we have specified > today. An UAS that did AIB would be perfectly correct > to reject a response that had proxy required where > things had been removed. Then I guess we already have a problem. According to table 3 in RFC 3261, a proxy is allowed to add option tags to a Proxy-Require header. I am not aware of anything that does this today, but it is certainly legal. If a UAC includes Proxy-Require in any kind of signature, it will fail if it goes thru a proxy that adds a tag. I checked AIB and did not see any reference to including Proxy-Require in a signed body. There are at least two RFCs (3323 and 3329) that have MUST level requirements to remove option tags from the Proxy-Require header. I think that is a proxy performs all of the require functionality for a given option such that no downstream proxy needs to support the option, it can and should be removed. The privacy and sec-agree are two examples documented today, although 3323 does indicate that a privacy service is a B2BUA. > > People bring up some of the 3G security stuff as a example > that this is ok - but that was something that was intended > for a specific and high controlled deployment model. It was > also something that has had some difficulties so I would > hardly use it as an example of why this is all alright. > > As EKR would say, the important high oder bit here is, > regardless of if we end up rewriting 3261 to make this > change or not, the discussion to make the decision is > probably not going to be short. > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 16:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuLp-0003wP-UD; Wed, 09 Aug 2006 16:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuLn-0003o0-Oy for sip@ietf.org; Wed, 09 Aug 2006 16:08:23 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAu8s-0004md-EZ for sip@ietf.org; Wed, 09 Aug 2006 15:55:03 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k79Jsx226847; Wed, 9 Aug 2006 15:54:59 -0400 (EDT) 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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 14:54:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF06F68BFA@zrc2hxm0.corp.nortel.com> In-Reply-To: <44D91EF7.8020102@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 thread-index: Aca7QzXXISneFw9PRqinXnceW6OsNwAjVQ/w From: "Francois Audet" To: "Dean Willis" , "Jeroen van Bemmel" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To me it seems natural that a Proxy would swallow the Proxy-Require for cases where it determines that it is the only Proxy that is required to support the capability, which is clearly the case here. I don't believe there is anything contracticting this interpretation in 3261. If it is a feature that is supposed to be end-to-end accross all proxies, then you'd leave it alone.=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, August 08, 2006 4:32 PM > To: Jeroen van Bemmel > Cc: IETF SIP List; Rohan Mahy > Subject: Re: [Sip] Outbound Issues: slides 3 and 4 >=20 > Jeroen van Bemmel wrote: >=20 > > Are you suggesting an alternative because there is something wrong=20 > > with the proposal from Rohan above? >=20 > The only thing I have seen in Rohan's proposal that makes=20 > people queazy is the handling of the proxy-require -- that=20 > is, removing it in the first hop proxy. >=20 > To quote a few IETF's back, "That doesn't bother me at all". >=20 > But it seems to bother Cullen and a few others, even if I did=20 > borrow his words to say I'm ok with it. >=20 > -- > Dean >=20 > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 16:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuLi-0003bh-BN; Wed, 09 Aug 2006 16:08:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuLg-0003YR-Bh for sip@ietf.org; Wed, 09 Aug 2006 16:08:16 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAuDD-00069p-Cv for sip@ietf.org; Wed, 09 Aug 2006 15:59:32 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 09 Aug 2006 12:59:31 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="1845667480:sNHT28150740" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79JxUvB030946; Wed, 9 Aug 2006 12:59:30 -0700 Received: from [192.168.1.2] (sjc-vpn4-138.cisco.com [10.21.80.138]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k79JxQuE007111; Wed, 9 Aug 2006 12:59:30 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F12FA@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F12FA@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A36F3AD-A280-46AD-9891-D16D98EA7765@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 12:59:27 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2595; t=1155153570; x=1156017570; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=N5uCnStWl9f4idgwc888mWDiysdFz7MkuhBDnXmOqx6qrTgcDoL7Yk5rLax4esxT2q86T2xn Dy+0mucFtZSAqX5+wImVD8KWBpPKVgJdgHtmHpJJcITV/WNpFpD+nHAI; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: IETF SIP List , Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 11:57 AM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >>> Cullen suggested an alternate possibility that might work. >>> >>> I'll try and paraphrase: >>> >>> A UAC which has an outbound URI indicating with ;keepalive=stun that >>> the next hop can support STUN messages on the SIP port needs to >>> verify > >>> the first hop supports STUN before repeatedly sending STUN messages. >>> The UAC may initially try sending STUN messages to the SIP port >>> of the > >>> first hop node. If the UAC does not receive a correct STUN response >>> (within some timer?) then it must assume that this mode does not >>> support STUN, and proceed without using STUN until it has some >>> evidence that the first-hop node might have changed, in which >>> case it >>> retries the STUN requests as per the initial attempt. >>> >>> I think it's probably okay to stun a server a few times before >>> deciding it doesn't like being stunned -- after all, the primary >>> risk >>> is one of slowing down service for the user doing the stunning, not >>> shutting down the server being stunned. What I object to is a >>> specification that says you go on stunning it indefinitely, perhaps >>> millions of times over the course of an association, with no way to >>> discover that you really shouldn't be stunning it. >>> >>> Set phasers on "stun", Mr. Sulu! >>> >>> -- >>> Dean > >> What I was trying to accomplish here was a solution that: >> >> 1) you don't send a STUN request until you receive a successful > response to the register, this lets you know the device >> you are about to send a stun request to is "up" >> >> 2) you send a small number of stun requests and if you don't get any > response, then you conclude that the server does not >> support stun and you stop stunning it >> >> As I mention on another email in this thread, I don't think it >> will be > practical to blacklist an IP after a single stun >> packet so I think this solution could probably work. > > Why can't the proxy, if it inserts a Path header, add > keepalive=stun to > that Path header? Then the UAC does not need to send stun request in > order to figure out whether the proxy supports STUN keepalive or not. > > (Of course, if the proxy does NOT support Path then the UAC may > have to > figure out by sending STUN requests.) > > Regards, > > Christer This would work for some deployments but imagine a simple UA connecting directly to a single proxy / registrar. In this simple case there would be no path headers. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 16:10:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuMT-00059D-8c; Wed, 09 Aug 2006 16:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuLg-0003YR-FU for sip@ietf.org; Wed, 09 Aug 2006 16:08:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAuD9-00069Z-H4 for sip@ietf.org; Wed, 09 Aug 2006 15:59:28 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2006 12:59:27 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="310758910:sNHT30535812" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79JxQHR032034; Wed, 9 Aug 2006 12:59:26 -0700 Received: from [192.168.1.2] (sjc-vpn4-138.cisco.com [10.21.80.138]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k79JxQuD007111; Wed, 9 Aug 2006 12:59:26 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F12FB@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F12FB@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ... Date: Wed, 9 Aug 2006 12:59:18 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=3436; t=1155153566; x=1156017566; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20=20-=20the =20problem=20...; X=v=3Dcisco.com=3B=20h=3DXGT2dZCkxDdI86zXSNI6kk3j5xw=3D; b=rfPr1GOqgCA07r0oMRQFM5stKK82Q8x35UUi+2hdNRtxXlJo8ljnMJYAgsElaYWqIO3HnHyP Sy5/C7PfsRaUC3IVGLn7uoImlc5lXm8WKQTV53JQ9p5zWZOwtbhVXo8L; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 12:07 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >>> We had a very long discussion in Montreal about discovery and >>> validation of a SIP outbound proxy server's ability to receive STUN >>> requests. While the vast majority of the room was comfortable that >>> "keepalive=stun" in a URI was a sufficient indicator that an >>> outbound >>> proxy supports SIP and STUN over the same port, a small but >>> extremely >>> vocal minority had significant problems with this assumption. >>> >>> Just so we are clear on the when this could be a problem.... >>> >> For any UA that is automatically configured, this is unlikely to >> every > be a problem. > > Assuming the UA is configured with a URI, yes. But, in case the UA > only > gets the IP address of the proxy, you still have a problem. Yep - let me update my response to Bob with something to take this into account... > > Because, EVEN if you require configured URIs with outbound, you can > use > STUN keepalive without outbound. > >> What we are talking about here is UA where some human types in the > configuration information to the UA. Even though they >> were told to enter example.com as the outbound proxy, they decide to > enter example.com;keep-alice=stun because perhaps >> they saw that in some other system. Their device sends a stun packet > and gets black listed. Note that any services that >> blacklists after receiving a single STUN packet with a spoofed IP > address is going to be trivial to totally DOS so I >> don't believe this sort of thing will deploy buts let continue down > this case. So the user UA does not work. It also >> would not have worked if they typed in elpmaxe.com (example >> backwards). > What do they do? read a web page, phone tech >> support, I have no idea but they do whatever they do when they > configure the outbound proxy information correction. >> Eventually they find out to remove the keep-alive=stun and their >> phone > starts working. >> >> For these reasons, I don't think this whole problem is not a huge >> deal. > However, if people do think it is a big deal, the >> obvious solution to it is send and OPTIONS message to find out if the > server supports this. > > If you want to know before you send the REGISTER request, you can do > that. But, again, I think the outbound proxy should be able to > indicate > the support, e.g. by inserting keepalive=stun in the Path header. Sure, I'm fine with the UA discovering URI via path or other mechanisms that have the flag then starting using it on connection to theses URI. But I think this is out of scope of this draft. > >> Most people don't seem to think this is enough of a problem to >> warrant > and additional RTT when a UA boots. We can come up >> with other possible solutions to this too (as there are at least >> three > others on this same thread). >> >> The meta question is simple - we had pretty strong consensus on >> this in > the meeting. How long do we really want to spend >> delaying this draft to find alternative solutions to this problem. > Clearly the answer different based on how serious a >> problem you think it is. > > I have presented an alternative solution :) If it doesn't work, fine, > but as far as I remember nobody has yet told me it doesn't work. > I will send email to that one too :-) > Regards, > > Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 16:18:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuUF-0001X8-AR; Wed, 09 Aug 2006 16:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuUE-0001X3-8w for sip@ietf.org; Wed, 09 Aug 2006 16:17:06 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAuUB-0002WU-Tq for sip@ietf.org; Wed, 09 Aug 2006 16:17:06 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-1.cisco.com with ESMTP; 09 Aug 2006 13:17:03 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79KH3LW011614; Wed, 9 Aug 2006 13:17:03 -0700 Received: from [192.168.1.2] (sjc-vpn4-138.cisco.com [10.21.80.138]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k79KH2uD016209; Wed, 9 Aug 2006 13:17:02 -0700 (PDT) In-Reply-To: <012701c6bbed$eece5260$800101df@acmepacket.com> References: <378641DE-FA7A-46E5-AE73-5954DF271BD4@cisco.com> <012701c6bbed$eece5260$800101df@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1DEDB974-911C-4851-8721-B0E63ED63DE8@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - B2BUA Proposal Date: Wed, 9 Aug 2006 13:16:55 -0700 To: Bob Penfield X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=3725; t=1155154623; x=1156018623; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20-=20B2BUA= 20Proposal; X=v=3Dcisco.com=3B=20h=3DOsIsa9l+QTO3JmDtPMXkIwT3SBw=3D; b=TERNUtoFHPphaCJHJogeb7whqd+mGAgYOyZbkPWrmlr+HDUa7VsBVJCy3JJnFDA9hc3/khjw 2tvHdNWdV4AmR+YDABVTyNZMMi4zcmUBKXmhRvjkk6mp9d/7Ew7a6CIR; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Bob - I really think that your other proposal is sounding like a good way to go to me but few points inline here ... On Aug 9, 2006, at 12:56 PM, Bob Penfield wrote: > inline > ----- Original Message ----- From: "Cullen Jennings" > > Sent: Wednesday, August 09, 2006 2:50 PM > Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - B2BUA Proposal > > >>> >> If I am reading 3261 correctly, the proxy would no longer be >> a proxy but a B2BUA. I had proposed this a long time ago and >> several people were very concerned about proxies >> modifying Proxy-Require headers. By the time they were >> done with me, I shared their concerns about doing that. >> This is a very slippery slope to be diving down if we >> ever expect to have some level of integrity around the >> only mechanism available in SIP for negotiation future >> forward compatibility with proxies. It would likely >> work with stuff that is deployed today but it is not >> backwards compatible with things we have specified >> today. An UAS that did AIB would be perfectly correct >> to reject a response that had proxy required where >> things had been removed. > > Then I guess we already have a problem. According to table 3 in RFC > 3261, a proxy is allowed to add option tags to a Proxy-Require > header. I am not aware of anything that does this today, but it is > certainly legal. If a UAC includes Proxy-Require in any kind of > signature, it will fail if it goes thru a proxy that adds a tag. > > I checked AIB and did not see any reference to including Proxy- > Require in a signed body. > > There are at least two RFCs (3323 and 3329) that have MUST level > requirements to remove option tags from the Proxy-Require header. I > think that is a proxy performs all of the require functionality for > a given option such that no downstream proxy needs to support the > option, it can and should be removed. The privacy and sec-agree are > two examples documented today, although 3323 does indicate that a > privacy service is a B2BUA. > True enough but I don't see a problem in that. I don't see a problem with 3261 having a proxy add things, it is the deleting or modifying that causes problems 3323 points out that In order to provide these functions the privacy service must frequently act as a transparent back-to-back user agent (B2BUA). Privacy services by definition have very different security properties. It probably impossible to have both some form of strong end 2 end integrity coupled with anonymization. I don't think anyone is thrilled with the what is possible in this space - just we can't come up with anything better at that point. As I mention below, 3329 is limited to environments where, quoting from the RFC Therefore, this extension should be used in environments where it is somehow ensured that every client implements this extension or is able to use TLS. The or use TLS is somewhat dubious because there is a chicken and egg problem in for the UA know what to do but that's sort of irrelevant for this discussion. >> >> People bring up some of the 3G security stuff as a example >> that this is ok - but that was something that was intended >> for a specific and high controlled deployment model. It was >> also something that has had some difficulties so I would >> hardly use it as an example of why this is all alright. >> >> As EKR would say, the important high oder bit here is, >> regardless of if we end up rewriting 3261 to make this >> change or not, the discussion to make the decision is >> probably not going to be short. >> _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 16:20:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuWC-0004P3-F2; Wed, 09 Aug 2006 16:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuWB-0004Mi-5w for sip@ietf.org; Wed, 09 Aug 2006 16:19:07 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAuW9-0003OX-Rc for sip@ietf.org; Wed, 09 Aug 2006 16:19:07 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 88AFB20A316; Wed, 9 Aug 2006 19:54:22 +0000 (UTC) Message-Id: <7.0.1.0.0.20060809212549.023cde90@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 09 Aug 2006 21:30:16 +0200 To: "Samir Srivastava" , "David R Oran" From: Jiri Kuthan Subject: RE: [Sip] Ciphersuites in SIP In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DB33BE2@zrc2hxm2.corp.nor tel.com> References: <7.0.1.0.0.20060806124311.02502c68@iptel.org> <62B9B0847CC47543B6B3B5E26BD268E60DB33BE2@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 07:27 08/08/2006, Samir Srivastava wrote: >Hi Jiri, > > My only requirement is, I should get the PSTN kind of security in >VoIP. I think with Internet you can do much better than that. Even today, when I make my calls using TLS and use zRTP I feel I'm getting way better security than with PSTN. I don't see how PSTN could outperform this. In terms of what I perceive as ideal, combination of hbh security for must-be-processed-by-proxy-stuff plus e2e security for everything else is just hard to beat. -jiri > In PSTN, I don't have to worry about the call pattern tracking etc >by anybody tapping on the wire. This can be done only under >CALEA by the duly authorized personnel when subpoena etc opened by the >legal authorities. I can talk my SSN, bank a/c etc without any fear. > > If SIP cannot provide this, then It will be bound to exist _only_ in >the *islands*. Which I (hope group also) don't like. Given Hop by Hop >nature of SIP, the proposal intended to address the issue within the >SIP framework. > >Thx >Samir > > >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri@iptel.org] >> Sent: Sunday, August 06, 2006 3:45 AM >> To: Srivastava, Samir (SC100:8826); David R Oran >> Cc: sip@ietf.org >> Subject: RE: [Sip] Ciphersuites in SIP >> >> Samir, >> >> I think your concerns relate generally to the transitive >> trust model lying under hop-by-hop security. All in all, you >> can't be in control of the whole path, make sure it is >> bug-free, super-secure, etc. If that concerns you, or your >> organization, I think you will be better off with e2e >> security protocols. >> >> -jiri >> -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 16:33:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuhx-0006WG-UP; Wed, 09 Aug 2006 16:31:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuhw-0006W8-FU for sip@ietf.org; Wed, 09 Aug 2006 16:31:16 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAuhv-0007AE-6m for sip@ietf.org; Wed, 09 Aug 2006 16:31:16 -0400 Received: from BPenfield [10.0.200.6] by acmepacket.com with ESMTP (SMTPD-9.03) id A60D0188; Wed, 09 Aug 2006 16:31:09 -0400 Message-ID: <01d601c6bbf2$c260ee90$800101df@acmepacket.com> From: "Bob Penfield" To: "Cullen Jennings" References: <0590a1057c40fa96aee3d22cb551fb87@telio.no> <002001c6bbce$b7a4dd50$800101df@acmepacket.com> <05D38DF0-A29A-42DB-B059-326A788FE576@cisco.com> Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 16:31:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I suppose that would work, but to guarantee that the outbound proxy acted as the UAS, you'd have to make the Request-URI be the proxy's address. Alternatively, you could include Proxy-Require: sip-stun and a Max-Forwards of 1. Or use Max-Forwards 0 and require the optional proxy behavior specified on page 95 of 3261. If the request contains a Max-Forwards header field with a field value of zero (0), the element MUST NOT forward the request. If the request was for OPTIONS, the element MAY act as the final recipient and respond per Section 11. Otherwise, the element MUST return a 483 (Too many hops) response. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Cullen Jennings" To: "Bob Penfield" Cc: "Hisham Khartabil" ; "Rohan Mahy" ; "IETF SIP List" Sent: Wednesday, August 09, 2006 2:56 PM Subject: Re: [Sip] Outbound Issues: slides 3 and 4 > > Hi Bob, > > How about if we said something like > > If the UA did not learn the outbound proxy set thru auto-config or > discovery mechanisms, then it MUST do an OPTIONS message first and check > for a sip-stun option tag. (clearly more wording needed but you know what > I mean) > > Would that work for you? I suspect it would work for most people. I'd > certainly be in favor of that. I suspect for proxies with millions of > users, they will use auto-config so this will not slow them down and for > proxies with UA with manual config, it will not be enough UA to cause a > huge performance impact. I don't know why I did not think of this > before. > > Cullen > > > On Aug 9, 2006, at 9:13 AM, Bob Penfield wrote: > >> I don't think the verification should be required, I just want to have a >> method to verify. That way, a UA that does not have a means to learn the >> outbound proxy set thru auto-config or discovery mechanisms can try to >> use outbound w/STUN. I would make it a MAY for the UA. > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 17:17:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvPN-0006F7-Vg; Wed, 09 Aug 2006 17:16:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvPM-0006EZ-A9 for sip@ietf.org; Wed, 09 Aug 2006 17:16:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAuae-0004tZ-Q1 for sip@ietf.org; Wed, 09 Aug 2006 16:23:44 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAu8g-00025M-GB for sip@ietf.org; Wed, 09 Aug 2006 15:54:52 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id F3E2920A314; Wed, 9 Aug 2006 19:54:17 +0000 (UTC) Message-Id: <7.0.1.0.0.20060809211738.05c60e18@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 09 Aug 2006 21:23:47 +0200 To: "Hadriel Kaplan" From: Jiri Kuthan Subject: RE: [Sip] Ciphersuites in SIP In-Reply-To: <07c501c6ba59$48542e90$6601a8c0@acmepacket.com> References: <7.0.1.0.0.20060806124853.055cfb50@iptel.org> <07c501c6ba59$48542e90$6601a8c0@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -2.2 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> For this statement, I don't think there is evidence. Based on my field >> experience I can only witness the opposite. Which is good -- mangling >> and hiding header fields is quite cumbersome when it comes down to >> actual operating a network. > >Well, this is off-topic, but I would guess that's because of the differing >customer bases we serve. :) thats indeed very likely. >Typically you won't know it's happened. All it takes for a multi-provider >multi-hop chain is for one of them to do it, and it's done. not really. The trouble is that with several SIP-mangling boxes in the path it may be even hard to find which of the boxes caused the trouble because they basically remove all kinds of "watermarks" based on some internal state. In other words, this is a problem to transparency (RFC 2775 explains a lot about that even though primarily focusing at IP level). > Whereas >assuming the Via's are all included and left alone requires all the hops to >do so. And devices other than SBCs do it too, but it's much more >fashionable to blame SBCs. Well I dont think I'm blaming SBCs, I'm blaming boxes that mangle SIP messages. As said, this causes loss of transparency. Which is not a fashion thing but an architectural issue. -jiri _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 17:20:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvRc-0001p2-Jp; Wed, 09 Aug 2006 17:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvRb-0001ox-C1 for sip@ietf.org; Wed, 09 Aug 2006 17:18:27 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAvRa-0004He-1O for sip@ietf.org; Wed, 09 Aug 2006 17:18:27 -0400 Received: from [64.101.149.124] (mikwils2-w2k.cisco.com [64.101.149.124]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k79LKVua031554 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 9 Aug 2006 16:20:32 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3175E6C9-1E67-444E-AE87-1E26360384F9@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ... Date: Wed, 9 Aug 2006 16:18:17 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 1:49 PM, Cullen Jennings wrote: > > Just so we are clear on the when this could be a problem.... > > For any UA that is automatically configured, this is unlikely to > every be a problem. What we are talking about here is UA where some > human types in the configuration information to the UA. Even though > they were told to enter example.com as the outbound proxy, they > decide to enter example.com;keep-alice=stun because perhaps they > saw that in some other system. Their device sends a stun packet and > gets black listed. Note that any services that blacklists after > receiving a single STUN packet with a spoofed IP address is going > to be trivial to totally DOS so I don't believe this sort of thing > will deploy buts let continue down this case. So the user UA does > not work. It also would not have worked if they typed in > elpmaxe.com (example backwards). What do they do? read a web page, > phone tech support, I have no idea but they do whatever they do > when they configure the outbound proxy information correction. > Eventually they find out to remove the keep-alive=stun and their > phone starts working. > I'm more worried about the scenario where the UA doesn't get blacklisted, but just throws a monkeywrench in performance, and it sucks just enough that people don't fix it but complain anyhow. > For these reasons, I don't think this whole problem is not a huge > deal. However, if people do think it is a big deal, the obvious > solution to it is send and OPTIONS message to find out if the > server supports this. Most people don't seem to think this is > enough of a problem to warrant and additional RTT when a UA boots. > We can come up with other possible solutions to this too (as there > are at least three others on this same thread). To recap: Unacceptable: If you're configured to use STUN, just keep STUNning whether it works or not. You may be dead, but you're right, and that's the important part. Alternatives: 1) Use an OPTIONS transaction before stunning to find out if the target supports STUN 2) Use any other SIP transaction (like REGISTER) to find out if the target supports STUN a) using a Proxy-Require b) Using some sort of Path: tagging 3) Just go ahead and STUN, and if it doesn't work, stop sending STUN. I'd be happy with 1+3 or 2+3. I'd even be happy with 1+3 where 1 is a "SHOULD" strength, but 3 needs to be a MUST. It may be common sense, but it requires documentation, and people seem to need "common sense" to have a MUST priority on it or they pretend it isn't important. If we go the 1-SHOULD+3-MUST route, we need to include the "Because the proxy might think your STUN is an attack or error condition and black-list you" as the explanation for the SHOULD. -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 17:24:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvVa-0004Jb-9D; Wed, 09 Aug 2006 17:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvVY-0004JW-Gx for sip@ietf.org; Wed, 09 Aug 2006 17:22:32 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAvVX-0004Xs-6y for sip@ietf.org; Wed, 09 Aug 2006 17:22:32 -0400 Received: from [64.101.149.124] (mikwils2-w2k.cisco.com [64.101.149.124]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k79LObIj031593 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 9 Aug 2006 16:24:38 -0500 In-Reply-To: References: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57139B31-1621-4A80-8FAC-1B6C79FAACF7@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 16:22:23 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 1:50 PM, Cullen Jennings wrote: > > 1) you don't send a STUN request until you receive a successful > response to the register, this lets you know the device you are > about to send a stun request to is "up" > Question inspired by Hisham: Aren't there address and port dependent mapping scenarios that seem to indicate that a UA should derive its effective contact address from doing a STUN to the SIP port of its proxy before registering? I thought that was one of the bonuses we got out of coaxial STUN and SIP. -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 17:37:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvht-00045M-NM; Wed, 09 Aug 2006 17:35:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvhs-00044s-0x for sip@ietf.org; Wed, 09 Aug 2006 17:35:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAvhq-0005f5-JX for sip@ietf.org; Wed, 09 Aug 2006 17:35:16 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2006 14:35:14 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="310794937:sNHT31278520" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79LZDwZ000372; Wed, 9 Aug 2006 14:35:13 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k79LZDuF027009; Wed, 9 Aug 2006 14:35:13 -0700 (PDT) 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); Wed, 9 Aug 2006 17:35:13 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:34:51 -0400 Message-ID: <44DA550E.9020602@cisco.com> Date: Wed, 09 Aug 2006 17:35:10 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> In-Reply-To: <1155070150.14419.18.camel@macbuster.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2006 21:34:51.0481 (UTC) FILETIME=[A5857490:01C6BBFB] DKIM-Signature: a=rsa-sha1; q=dns; l=2962; t=1155159313; x=1156023313; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Question=20regarding=20instance=20ID=20in=20GRUU=20and=2 0outbound; X=v=3Dcisco.com=3B=20h=3DW1oZffcBbE4wp5P7F4LQfSRhG6E=3D; b=D4jZWy5hoE/m46ALZcvRd0RlvfZteMmymBpPTBW0jab/1zELIDTDKB86HFiSauvF25VhJw/s BQKztds15Hpb613UoQzKjdEF1Wgr7TPzciVnN4xEsf6sJ944y4NBcNJ3; Authentication-Results: sj-dkim-6.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki, Can you point to anything wrong with the current approach? The only evidence of a problem that I saw in this discussion was that it would be harder to implement UUID URN than a cookie mechanism. YMMV on that one. Consequently, if it aint broke - don't fix it. I am loathe to reopen the whole gruu/outbound design technique without a concrete problem being identified. I also think its easier for a server to remember an instance ID to GRUU binding for a long time, than it is for a client to remember its cookie for a long time AND for the server to remember the cookie to GRUU mapping for a long time. GRUU persistence would depend on a client remembering its cookie basically forever. GRUU currently doesn't require persistent storage of any soft state in the client. -Jonathan R. Aki Niemi wrote: > Howdy, > > I read GRUU and outbound, and an old nagging concern of mine resurfaced: > what the heck do we need the instance ID for? > > Seems outbound uses it to guarantee uniqueness of flows in a registrar, > but to me it sounds weird that the task of acquiring unique IDs within > the registrar's internal state is left to the UA -- after all, browsers > don't generally generate cookies themselves but store whatever the > website gives them. > > To me, a much better approach would be to have the registrar generate > and allocate a unique ID (perhaps the 'opaque' used in GRUU?) for the > first REGISTER, and whenever a client registers with that ID again, it > is deemed the same UA. A REGISTER without an ID would be another UA > instance. > > Even DHCP clients' leases seem to survive reboots without some weird URN > generation, so I don't think that it's unreasonable to require UAs to > store their outbound IDs either. I mean, they already have to store the > reg-id, no? (Not to mention web cookies...) > > And worst case is you need to garbage-collect some stale flows, in case > a UA happens to forget its ID, but that you need to be doing in any > case. > > We chose a similar approach over instance ID in PUBLISH, which uses > etags generated by the server to identify uniqueness of publisher > instances. With PUBLISH, UAs are also instructed to remember their > etags, even across reboots. > > Cheers, > Aki > > > _______________________________________________ > Sip mailing list https://www1.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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 17:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvpi-0003Bx-Lo; Wed, 09 Aug 2006 17:43:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvph-0003Bs-3c for sip@ietf.org; Wed, 09 Aug 2006 17:43:21 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAvpf-0006bJ-RL for sip@ietf.org; Wed, 09 Aug 2006 17:43:21 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A6F6015C; Wed, 09 Aug 2006 17:43:18 -0400 From: "Hadriel Kaplan" To: "'Cullen Jennings'" Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 17:43:18 -0400 Message-ID: <018201c6bbfc$d3ee7290$b7c8000a@acmepacket.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.2869 Thread-Index: Aca75KtyOZi6aRRSSiajArapenRmlwADwfyQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > > What I was trying to accomplish here was a solution that: > > 1) you don't send a STUN request until you receive a successful > response to the register, this lets you know the device you are about > to send a stun request to is "up" > > 2) you send a small number of stun requests and if you don't get any > response, then you conclude that the server does not support stun and > you stop stunning it > > As I mention on another email in this thread, I don't think it will > be practical to blacklist an IP after a single stun packet so I think > this solution could probably work. It won't be one single stun, as the UAC has to resend several in case of packet loss. In my opinion blacklisting it may actually be the right thing to do, oddly enough. But that's not my concern. My concerns/issues are: (1) A way to let the operator of the proxy know something's amiss and correct it. That is more likely with a proxy-require sip-stun option tag, because a proxy which does not understand outbound would (hopefully) log this required thing it doesn't support, and the operator can simply google "sip-stun" and find this RFC. (I know, that's a simplistic view) (2) this is a mechanism which REQUIRES a proxy to do something, to work correctly, but doesn't want to use the SIP-defined mechanism to do so. Why? Every other extension has a ACK/NACK mechanism in SIP, except for the one that is arguably one of the biggest changes. (3) checking a server supports a malformed message by actually sending the malformed message is, well, simply rude. :) It makes this draft a new torture test; as I said in Montreal I doubt any maker of SIP products on this mailing list or WG would have a problem with stun messages. (though one would have thought that back when Protos first came out, too) -hadriel p.s. Fredrik: yes, round and round we go. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 17:48:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvsc-0005Vg-Oh; Wed, 09 Aug 2006 17:46:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvsa-0005VX-VU for sip@ietf.org; Wed, 09 Aug 2006 17:46:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAuad-0004sq-4b for sip@ietf.org; Wed, 09 Aug 2006 16:23:43 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAuLa-0002FO-JE for sip@ietf.org; Wed, 09 Aug 2006 16:08:12 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7DF394F0046; Wed, 9 Aug 2006 22:07:55 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 22:07:54 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 22:07:54 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 - using Path/Supported to indicate STUN keepalive support Date: Wed, 9 Aug 2006 22:07:53 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1302@esealmw113.eemea.ericsson.se> In-Reply-To: <6A36F3AD-A280-46AD-9891-D16D98EA7765@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 - using Path/Supported to indicate STUN keepalive support Thread-Index: Aca77lhUK4Lus1ulT8SxmBsnh0OGcwAAH2Hw From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" X-OriginalArrivalTime: 09 Aug 2006 20:07:54.0507 (UTC) FILETIME=[7FF665B0:01C6BBEF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List , Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Why can't the proxy, if it inserts a Path header, add keepalive=3Dstun = >>to that Path header? Then the UAC does not need to send stun request=20 >>in order to figure out whether the proxy supports STUN keepalive or=20 >>not. >> >>(Of course, if the proxy does NOT support Path then the UAC may have=20 >>to figure out by sending STUN requests.) >> >This would work for some deployments but imagine a simple UA connecting directly to a single proxy / registrar. In this=20 >simple case there would be no path headers. > In that case the proxy/registrar could insert an option-tag in the Supported header, to indicate it supports STUN keepalive (similar to outbound). And, if we change "keepalive=3Dstun" to something which also fits the option-tag syntax we could use the same value in both=20 the Path and Supported header. Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 17:52:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvwj-0000pf-1o; Wed, 09 Aug 2006 17:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvwg-0000pZ-Qq for sip@ietf.org; Wed, 09 Aug 2006 17:50:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAvwf-0007ef-CV for sip@ietf.org; Wed, 09 Aug 2006 17:50:34 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2006 17:50:33 -0400 X-IronPort-AV: i="4.08,107,1154923200"; d="scan'208"; a="95937079:sNHT28214756" 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.20060308/8.12.11) with ESMTP id k79LoXHq018696; Wed, 9 Aug 2006 17:50:33 -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.12.10/8.12.6) with ESMTP id k79LoWdp012839; Wed, 9 Aug 2006 17:50:33 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:50:32 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:50:32 -0400 Message-ID: <44DA58A8.2020307@cisco.com> Date: Wed, 09 Aug 2006 17:50:32 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hisham Khartabil Subject: using mapped addresses from stun in sip-outbound, was: Re: [Sip] Outbound Issues: slides 3 and 4 References: <0590a1057c40fa96aee3d22cb551fb87@telio.no> In-Reply-To: <0590a1057c40fa96aee3d22cb551fb87@telio.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2006 21:50:32.0267 (UTC) FILETIME=[D64601B0:01C6BBFD] DKIM-Signature: a=rsa-sha1; q=dns; l=5226; t=1155160233; x=1156024233; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:using=20mapped=20addresses=20from=20stun=20in=20sip-outbound, =20was=3A=2 0Re=3A=20[Sip]=0A=20Outbound=20Issues=3A=20slides=203=20and=204 |To:Hisham=20Khartabil=20; X=v=3Dcisco.com=3B=20h=3DlBs1dc6ad0dswuOOEW9xlETzO/g=3D; b=NRrcsTMIS+T+2tjF1+F7pG1kU6svqmaq2j+WwuuF123qT5ffZ/sxNOMBEV0Tz45EgCQ+laF6 7g3lD0VauDWlCbyltayfXq5yMZ0GOkxq5bXe4GKuld7iN3DiYdCE3DOO; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org changing topics here. Hisham - why would you want to do this? The whole idea of sip-outbound is to make the IP in the Contact irrelevant. It will be ignored anyway. Perhaps you are worried about an outbound proxy that supports stun but a registrar that doesn't support sip-outbound? There are some pretty sizeable security risks in doing this. In particular, as long as the client doesn't actually use the mapped address that comes back - but rather uses it as a hint to go do something else - you can get away without authenticating the stun transactions. If you actually use the mapped address from the stun response in the Contact, an attacker can send a spoofed stun response can incoming calls get routed to him instead. This is partly (and only partly) fixable if you authenticate stun responses. However, once you require stun authentication then the whole performance benefit of stun goes away. Thanks, Jonathan R. Hisham Khartabil wrote: > I don't like this proposal. I'm still with the camp that says: if > configured, then it must be true. > > My main objection is that in this proposal, you are required to send SIP > messages before STUN messages. That's a mandate that I'm not comfortable > with since I might want to send STUN first to discover my public IP/port > to populate the contact header before I send the first REGISTER. > > Hisham > > On Aug 8, 2006, at 4:38 PM, Rohan Mahy wrote: > >> >> We had a very long discussion in Montreal about discovery and >> validation of a SIP outbound proxy server's ability to receive STUN >> requests. While the vast majority of the room was comfortable that >> "keepalive=stun" in a URI was a sufficient indicator that an outbound >> proxy supports SIP and STUN over the same port, a small but extremely >> vocal minority had significant problems with this assumption. After a >> discussion with Dean, I am willing to try a validation proposal which >> adds no extra round trips if the SIP UA was indeed correctly configured. >> >> The specific proposal works like this. A UAC which has an outbound >> URI indicating with ;keepalive=stun that the next hop can support STUN >> messages on the SIP port, needs to verify the first hop supports STUN >> before sending any STUN messages. The UAC sends its first SIP message >> to the next hop with a Proxy-Require: sip-stun. If the URI was >> correct (STUN was supported), and the first-hop is an intermediary, >> the first-hop removes the Proxy-Require and forwards the SIP request >> (probably a REGISTER request) along adding no additional delay. A >> positive response to a REGISTER or OPTIONS with Supported: outbound >> and no error counts as positive confirmation that either the registrar >> supports STUN or expects to never receive a request without getting it >> from an outbound proxy which did not complain about the Proxy-Require >> [1]. If the UAC was misconfigured (the first-hop intermediary does not >> support STUN keepalives), either the first hop will reject the SIP >> request (if it is an intermediary), or the registrar will not include >> an indicator that it supports outbound (if the first hop was the >> registrar). >> >> Note that this proposal is not a full *discovery* mechanism, just a >> verification mechanism. For example, if the registrar doesn't support >> outbound, but the first-hop does, there is no way described here to >> discover that the first-hop can accept STUN keepalives. Do not >> confuse support of STUN with support of outbound. Supported: outbound >> implies that the registrar supports STUN or is configured to use an >> outbound proxy that does. The sip-stun option tag only means that you >> can send and receive STUN requests on your SIP port. While outbound >> requires STUN, STUN does not require outbound. >> >> [1] Also Note that there is a caveat that you can still shoot yourself >> in the foot if you allow messages to come straight to your registrar >> that does not support STUN. I think we agreed that we are not going >> to enumerate all the ways you can subtly break things in SIP though. >> >> thanks, >> -rohan >> >> >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 17:54:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvyR-0002Ww-N5; Wed, 09 Aug 2006 17:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvyQ-0002Uy-CE for sip@ietf.org; Wed, 09 Aug 2006 17:52:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAvyO-0007oJ-0a for sip@ietf.org; Wed, 09 Aug 2006 17:52:22 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2006 14:52:20 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="310800242:sNHT29160724" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79LqJRA008341; Wed, 9 Aug 2006 14:52:19 -0700 Received: from [192.168.1.2] (sjc-vpn4-138.cisco.com [10.21.80.138]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k79LqIuD004263; Wed, 9 Aug 2006 14:52:19 -0700 (PDT) In-Reply-To: <01d601c6bbf2$c260ee90$800101df@acmepacket.com> References: <0590a1057c40fa96aee3d22cb551fb87@telio.no> <002001c6bbce$b7a4dd50$800101df@acmepacket.com> <05D38DF0-A29A-42DB-B059-326A788FE576@cisco.com> <01d601c6bbf2$c260ee90$800101df@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 14:52:11 -0700 To: Bob Penfield X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2799; t=1155160339; x=1156024339; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=oYFQxGTDwyFUFLQhIjJG6sWPrFFcC0OpbI95LldjpKeMaSYXYzmPjvTF3OtlvSZrCJJGIadn z0hM1VK3j6ukOyqiM859t4wkzdBqlq3bl4+p2jc6kxvKzohe0/47dClP; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 1:31 PM, Bob Penfield wrote: > I suppose that would work, but to guarantee that the outbound proxy > acted as the UAS, you'd have to make the Request-URI be the proxy's > address. > Agreed - I think like this better than your next alternative since you have the the address but either could work > Alternatively, you could include Proxy-Require: sip-stun and a Max- > Forwards of 1. Or use Max-Forwards 0 and require the optional proxy > behavior specified on page 95 of 3261. > > If the request contains a Max-Forwards header field with a field > value of zero (0), the element MUST NOT forward the request. If > the request was for OPTIONS, the element MAY act as the final > recipient and respond per Section 11. Otherwise, the element MUST > return a 483 (Too many hops) response. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 71 Third Avenue > Burlington, MA 01803 > bpenfield@acmepacket.com > > ----- Original Message ----- From: "Cullen Jennings" > > To: "Bob Penfield" > Cc: "Hisham Khartabil" ; "Rohan Mahy" > ; "IETF SIP List" > Sent: Wednesday, August 09, 2006 2:56 PM > Subject: Re: [Sip] Outbound Issues: slides 3 and 4 > > >> >> Hi Bob, >> >> How about if we said something like >> >> If the UA did not learn the outbound proxy set thru auto-config or >> discovery mechanisms, then it MUST do an OPTIONS message first >> and check for a sip-stun option tag. (clearly more wording needed >> but you know what I mean) >> >> Would that work for you? I suspect it would work for most people. >> I'd certainly be in favor of that. I suspect for proxies with >> millions of users, they will use auto-config so this will not slow >> them down and for proxies with UA with manual config, it will not >> be enough UA to cause a huge performance impact. I don't know why >> I did not think of this before. >> >> Cullen >> >> >> On Aug 9, 2006, at 9:13 AM, Bob Penfield wrote: >> >>> I don't think the verification should be required, I just want >>> to have a method to verify. That way, a UA that does not have a >>> means to learn the outbound proxy set thru auto-config or >>> discovery mechanisms can try to use outbound w/STUN. I would >>> make it a MAY for the UA. > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 17:59:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw3v-0005bD-GV; Wed, 09 Aug 2006 17:58:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw3u-0005b8-Ce for sip@ietf.org; Wed, 09 Aug 2006 17:58:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAw3s-0008Vr-2N for sip@ietf.org; Wed, 09 Aug 2006 17:58:02 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2006 17:58:00 -0400 X-IronPort-AV: i="4.08,107,1154923200"; d="scan'208"; a="95937983:sNHT136845464" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79LvxaW019528; Wed, 9 Aug 2006 17:57:59 -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.12.10/8.12.6) with ESMTP id k79Lvxdp014722; Wed, 9 Aug 2006 17:57:59 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:57:59 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:57:58 -0400 Message-ID: <44DA5A66.70403@cisco.com> Date: Wed, 09 Aug 2006 17:57:58 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ... References: <5EB80D22825EEE42872083AD5BFFB594017F12FB@esealmw113.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2006 21:57:58.0966 (UTC) FILETIME=[E086DD60:01C6BBFE] DKIM-Signature: a=rsa-sha1; q=dns; l=2318; t=1155160679; x=1156024679; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20=20-=20the =20problem=20... |To:Cullen=20Jennings=20; X=v=3Dcisco.com=3B=20h=3DbtjLD/bLk+/Bp+GHie2iWikqDjs=3D; b=0bMI2Xr2vq8h1dEkLOg3L6GM2FrxvXxxIIzmE14W1E3Sc/9MMIfR8GlOctRZoCeKr2VPyivR FKBFmCb2KI0/jZsz6RqAcuquxxjVZHhBDpMU+SsxwjcT89xq3Df04xe2; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List , Rohan Mahy , "Christer Holmberg \(\(JO/LMF\)\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Cullen Jennings wrote: >> If you want to know before you send the REGISTER request, you can do >> that. But, again, I think the outbound proxy should be able to indicate >> the support, e.g. by inserting keepalive=stun in the Path header. > > > Sure, I'm fine with the UA discovering URI via path or other mechanisms > that have the flag then starting using it on connection to theses URI. > But I think this is out of scope of this draft. I agree its out of scope. But its relevant here as it comes back to problem statement. The root issue here is that someone constructs a URI with keepalive=stun when it shouldn't have. There are two reasons we've been discussing why this might happen: 1. a user types in their outbound proxy and adds keepalive=stun when they shouldn't have 2. outbound proxy is discovered via DHCP, and since DHCP provides a hostname and not a URI, a UA constructs a URI, and since it supports the stun keepalive adds the parameter Case #2 is a legitimate cause for concern. However if we had a mechanism for autodiscovery of outbound proxies, where a URI was provided by that proxy itself, then this use case goes away, and the need for some of these verification mechanisms goes away too. So, I had proposed at the mike during ietf a mechanism for discovery using Service-Route (Path is the wrong direction), which would make sure that, even if a client discovers the proxy initially via DHCP, it quickly learns a URI from that proxy which would inform it about whether stun is supported. Draft coming soon on this... If we had such a mechanism, then I dont think we need any of this mess. In particular, though I dont really see a lot of harm in Rohans Proxy-Require proposal, I think its unnecessary complexity if you have a proper discovery mechanim. Since we need a proper discovery mechanism regardless lets solve that problem and ditch the extra mechanism. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 18:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw5Z-0006X4-P9; Wed, 09 Aug 2006 17:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw5Y-0006Wu-3I for sip@ietf.org; Wed, 09 Aug 2006 17:59:44 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAw5W-0000Bo-PM for sip@ietf.org; Wed, 09 Aug 2006 17:59:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2006 17:59:43 -0400 X-IronPort-AV: i="4.08,107,1154923200"; d="scan'208"; a="95938207:sNHT26312864" 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.20060308/8.12.11) with ESMTP id k79LxgIP022099; Wed, 9 Aug 2006 17:59:42 -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.12.10/8.12.6) with ESMTP id k79Lxge2024003; Wed, 9 Aug 2006 17:59:42 -0400 (EDT) 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); Wed, 9 Aug 2006 17:59:42 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:59:41 -0400 Message-ID: <44DA5ACC.2040700@cisco.com> Date: Wed, 09 Aug 2006 17:59:40 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - using Path/Supported to indicate STUN keepalive support References: <5EB80D22825EEE42872083AD5BFFB594017F1302@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1302@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2006 21:59:41.0751 (UTC) FILETIME=[1DCA9C70:01C6BBFF] DKIM-Signature: a=rsa-sha1; q=dns; l=1705; t=1155160782; x=1156024782; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20-=20using= 20Path/Supported=0A=20to=09indicate=20STUN=20keepalive=20support |To:=22Christer=20Holmberg=20(JO/LMF)=22=20; X=v=3Dcisco.com=3B=20h=3DfquyqFeMafi9JvcCg+R2a1rKmVI=3D; b=lLMyooygc34243jBm8LvVhhTIY4ZXXrllj2QDHsCGch0FbQoxOCkhz5zgyDBEHL7j5WLlAof dSFQPtm05EfFMxlKL6qZad3zQGtmb1nS5YGtpnZacXYCEV6OlxrEoJxO; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Cullen Jennings , IETF SIP List , Dean Willis , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, IMHO in this case it would simply use Path anyway, pointing to itself. -Jonathan R. Christer Holmberg (JO/LMF) wrote: > Hi, > > >>>Why can't the proxy, if it inserts a Path header, add keepalive=stun >>>to that Path header? Then the UAC does not need to send stun request >>>in order to figure out whether the proxy supports STUN keepalive or >>>not. >>> >>>(Of course, if the proxy does NOT support Path then the UAC may have >>>to figure out by sending STUN requests.) >>> >> >>This would work for some deployments but imagine a simple UA connecting > > directly to a single proxy / registrar. In this > >>simple case there would be no path headers. >> > > In that case the proxy/registrar could insert an option-tag in the > Supported header, to indicate it supports STUN keepalive (similar to > outbound). > > And, if we change "keepalive=stun" to something which also fits the > option-tag syntax we could use the same value in both > the Path and Supported header. > > Regards, > > Christer > > _______________________________________________ > Sip mailing list https://www1.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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 18:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw5a-0006Xf-P9; Wed, 09 Aug 2006 17:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw5Y-0006Wz-Of for sip@ietf.org; Wed, 09 Aug 2006 17:59:44 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAw5X-0000Bp-Fq for sip@ietf.org; Wed, 09 Aug 2006 17:59:44 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2006 14:59:44 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="310802456:sNHT26514544" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79Lxg2Z029082; Wed, 9 Aug 2006 14:59:42 -0700 Received: from [192.168.1.2] (sjc-vpn4-138.cisco.com [10.21.80.138]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79LxgIZ000295; Wed, 9 Aug 2006 14:59:42 -0700 (PDT) In-Reply-To: <57139B31-1621-4A80-8FAC-1B6C79FAACF7@softarmor.com> References: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> <57139B31-1621-4A80-8FAC-1B6C79FAACF7@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 14:59:35 -0700 To: Dean Willis X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1318; t=1155160782; x=1156024782; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=F6wVknL1OGB8plU/Q5+ncCRZErOfNPrwNsDS9Dum0dOqNrm9xL82hJDRWGINsrW/dCq72Alc MG3ujLFO7f2E5Qt214isgG/RRgDb+dA3WHNsLfnuBQyKWZdARrY+LksB; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 2:22 PM, Dean Willis wrote: > > On Aug 9, 2006, at 1:50 PM, Cullen Jennings wrote: > > >> >> 1) you don't send a STUN request until you receive a successful >> response to the register, this lets you know the device you are >> about to send a stun request to is "up" >> > > Question inspired by Hisham: Aren't there address and port > dependent mapping scenarios that seem to indicate that a UA should > derive its effective contact address from doing a STUN to the SIP > port of its proxy before registering? I thought that was one of the > bonuses we got out of coaxial STUN and SIP. > > -- > Dean > If you are doing outbound, it does not matter what IP you put in the contact - presumably devices will use things like their private IP address. In the cases where you are not doing outbound, you need to be configured with a stun server if you want to use stun to find your public IP address, how a UA would check that the stun server it is configured to use is correct before sending it any stun messages is a problem I would like to keep out of scope of the outbound draft. Using the outbound proxy even if it did support stun would be pretty risky because it might be inside one of the NAT layers and not in an public IP space. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 18:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw5Z-0006X4-P9; Wed, 09 Aug 2006 17:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw5Y-0006Wu-3I for sip@ietf.org; Wed, 09 Aug 2006 17:59:44 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAw5W-0000Bo-PM for sip@ietf.org; Wed, 09 Aug 2006 17:59:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2006 17:59:43 -0400 X-IronPort-AV: i="4.08,107,1154923200"; d="scan'208"; a="95938207:sNHT26312864" 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.20060308/8.12.11) with ESMTP id k79LxgIP022099; Wed, 9 Aug 2006 17:59:42 -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.12.10/8.12.6) with ESMTP id k79Lxge2024003; Wed, 9 Aug 2006 17:59:42 -0400 (EDT) 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); Wed, 9 Aug 2006 17:59:42 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:59:41 -0400 Message-ID: <44DA5ACC.2040700@cisco.com> Date: Wed, 09 Aug 2006 17:59:40 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - using Path/Supported to indicate STUN keepalive support References: <5EB80D22825EEE42872083AD5BFFB594017F1302@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1302@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2006 21:59:41.0751 (UTC) FILETIME=[1DCA9C70:01C6BBFF] DKIM-Signature: a=rsa-sha1; q=dns; l=1705; t=1155160782; x=1156024782; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20-=20using= 20Path/Supported=0A=20to=09indicate=20STUN=20keepalive=20support |To:=22Christer=20Holmberg=20(JO/LMF)=22=20; X=v=3Dcisco.com=3B=20h=3DfquyqFeMafi9JvcCg+R2a1rKmVI=3D; b=lLMyooygc34243jBm8LvVhhTIY4ZXXrllj2QDHsCGch0FbQoxOCkhz5zgyDBEHL7j5WLlAof dSFQPtm05EfFMxlKL6qZad3zQGtmb1nS5YGtpnZacXYCEV6OlxrEoJxO; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Cullen Jennings , IETF SIP List , Dean Willis , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, IMHO in this case it would simply use Path anyway, pointing to itself. -Jonathan R. Christer Holmberg (JO/LMF) wrote: > Hi, > > >>>Why can't the proxy, if it inserts a Path header, add keepalive=stun >>>to that Path header? Then the UAC does not need to send stun request >>>in order to figure out whether the proxy supports STUN keepalive or >>>not. >>> >>>(Of course, if the proxy does NOT support Path then the UAC may have >>>to figure out by sending STUN requests.) >>> >> >>This would work for some deployments but imagine a simple UA connecting > > directly to a single proxy / registrar. In this > >>simple case there would be no path headers. >> > > In that case the proxy/registrar could insert an option-tag in the > Supported header, to indicate it supports STUN keepalive (similar to > outbound). > > And, if we change "keepalive=stun" to something which also fits the > option-tag syntax we could use the same value in both > the Path and Supported header. > > Regards, > > Christer > > _______________________________________________ > Sip mailing list https://www1.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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 18:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw5a-0006Xf-P9; Wed, 09 Aug 2006 17:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw5Y-0006Wz-Of for sip@ietf.org; Wed, 09 Aug 2006 17:59:44 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAw5X-0000Bp-Fq for sip@ietf.org; Wed, 09 Aug 2006 17:59:44 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2006 14:59:44 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="310802456:sNHT26514544" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79Lxg2Z029082; Wed, 9 Aug 2006 14:59:42 -0700 Received: from [192.168.1.2] (sjc-vpn4-138.cisco.com [10.21.80.138]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79LxgIZ000295; Wed, 9 Aug 2006 14:59:42 -0700 (PDT) In-Reply-To: <57139B31-1621-4A80-8FAC-1B6C79FAACF7@softarmor.com> References: <20FC5D76-79A0-498D-B048-26CAD2DD1A7F@softarmor.com> <57139B31-1621-4A80-8FAC-1B6C79FAACF7@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 14:59:35 -0700 To: Dean Willis X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1318; t=1155160782; x=1156024782; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=F6wVknL1OGB8plU/Q5+ncCRZErOfNPrwNsDS9Dum0dOqNrm9xL82hJDRWGINsrW/dCq72Alc MG3ujLFO7f2E5Qt214isgG/RRgDb+dA3WHNsLfnuBQyKWZdARrY+LksB; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 2:22 PM, Dean Willis wrote: > > On Aug 9, 2006, at 1:50 PM, Cullen Jennings wrote: > > >> >> 1) you don't send a STUN request until you receive a successful >> response to the register, this lets you know the device you are >> about to send a stun request to is "up" >> > > Question inspired by Hisham: Aren't there address and port > dependent mapping scenarios that seem to indicate that a UA should > derive its effective contact address from doing a STUN to the SIP > port of its proxy before registering? I thought that was one of the > bonuses we got out of coaxial STUN and SIP. > > -- > Dean > If you are doing outbound, it does not matter what IP you put in the contact - presumably devices will use things like their private IP address. In the cases where you are not doing outbound, you need to be configured with a stun server if you want to use stun to find your public IP address, how a UA would check that the stun server it is configured to use is correct before sending it any stun messages is a problem I would like to keep out of scope of the outbound draft. Using the outbound proxy even if it did support stun would be pretty risky because it might be inside one of the NAT layers and not in an public IP space. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 18:03:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw7G-0008OH-69; Wed, 09 Aug 2006 18:01:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAw7F-0008OC-Fg for sip@ietf.org; Wed, 09 Aug 2006 18:01:29 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAw7E-0000H2-0k for sip@ietf.org; Wed, 09 Aug 2006 18:01:29 -0400 Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k79M1Rap015883 for ; Wed, 9 Aug 2006 18:01:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Aug 2006 18:01:27 -0400 Message-ID: <6B3E29721F78364AA2C43697AFB15D91038F6A@sonusmail07.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Undefined UAS behaviour in RFC3261 12.2.2 Thread-Index: Aca7/1yrp0tl05t7Se6AAqe1XqK+Kw== From: "Molodyko, Rostislav" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Subject: [Sip] Undefined UAS behaviour in RFC3261 12.2.2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1303477539==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1303477539== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BBFF.5CE91767" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BBFF.5CE91767 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, The section 12.2.2 "UAS Behavior" states that UAS should : - reject the requests "If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number" - consider the request in-order if "the sequence number of the request is greater than the remote sequence number"=20 Not clear what UAS behaviour should be if the sequence number is equal to the remote sequence number, but the incoming request is a new request (not a retransmission).=20 In the example below UAC sends UPDATE with the same Cseq like PRACK. I guess UAS should reject that UPDATE with 500 or 4xx, while it is not stated in RFC. At UAC side: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TRANSMITTED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D INVITE sip:6667171111@10.13.15.107:4000 SIP/2.0 Call-ID: 4317683@10.7.6.40 CSeq: 10 INVITE ... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RECEIVED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SIP/2.0 180 Ringing Call-ID: 4317683@10.7.6.40 CSeq: 10 INVITE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TRANSMITTED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D PRACK sip:6667171111@10.13.15.107:4000 SIP/2.0 Call-ID: 4317683@10.7.6.40 CSeq: 11 PRACK ... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RECEIVED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SIP/2.0 200 OK Call-ID: 4317683@10.7.6.40 CSeq: 11 PRACK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TRANSMITTED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D UPDATE sip:6667171111@10.13.15.107:4000 SIP/2.0 Call-ID: 4317683@10.7.6.40 CSeq: 11 UPDATE ... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RECEIVED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SIP/2.0 200 OK // ??? Call-ID: 4317683@10.7.6.40 CSeq: 11 UPDATE Is this case covered by any new RFC or Draft? Regards, Ros Molodyko SIP Development Sonus Networks 250 Apollo Drive Chelmsford, MA 01824 Direct phone: 978-614-8620 =20 ------_=_NextPart_001_01C6BBFF.5CE91767 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Undefined UAS behaviour in RFC3261 12.2.2

Hi = All,

        The section 12.2.2 “UAS Behavior” states that UAS = should = :

-       = reject the requests “If the remote sequence = number was not empty, but the sequence number of the request is lower = than the remote sequence number”

-       consider the request in-order if “the sequence number of the = request is greater than the remote sequence = number”

      Not = clear what UAS behaviour should be if the sequence = number is equal to = the remote sequence number, but the incoming request is a new request (not a retransmission).

        In the example below UAC sends UPDATE with the same Cseq = like PRACK. I guess UAS should reject that UPDATE with 500 or 4xx, while = it is not stated in RFC.

At = UAC side:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TRANSMITTED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D

INVITE sip:6667171111@10.13.15.107:4000 SIP/2.0

Call-ID: 4317683@10.7.6.40

CSeq: 10 INVITE

...

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RECEIVED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

SIP/2.0 180 Ringing

Call-ID: 4317683@10.7.6.40

CSeq: 10 INVITE

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TRANSMITTED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D

PRACK sip:6667171111@10.13.15.107:4000 = SIP/2.0

Call-ID: 4317683@10.7.6.40

CSeq: 11 PRACK

...

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RECEIVED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

SIP/2.0 200 OK

Call-ID: 4317683@10.7.6.40

CSeq: 11 PRACK

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TRANSMITTED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D

UPDATE sip:6667171111@10.13.15.107:4000 = SIP/2.0

Call-ID: 4317683@10.7.6.40

CSeq: 11 UPDATE

...

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RECEIVED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

SIP/2.0 200 OK          =         =         // ???

Call-ID: 4317683@10.7.6.40

CSeq: 11 UPDATE

        Is this case covered by any new RFC or = Draft?

Regards,

Ros = Molodyko

SIP = Development

Sonus = Networks

250 = Apollo Drive

Chelmsford, MA 01824

Direct phone: 978-614-8620

 

------_=_NextPart_001_01C6BBFF.5CE91767-- --===============1303477539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============1303477539==-- From sip-bounces@ietf.org Wed Aug 09 18:14:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwIS-0000sl-94; Wed, 09 Aug 2006 18:13:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwIQ-0000rY-Mr for sip@ietf.org; Wed, 09 Aug 2006 18:13:02 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAwIP-0002FP-C5 for sip@ietf.org; Wed, 09 Aug 2006 18:13:02 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 09 Aug 2006 15:13:00 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="1845723410:sNHT27115144" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79MD0tw002311; Wed, 9 Aug 2006 15:13:00 -0700 Received: from [192.168.1.2] (sjc-vpn4-138.cisco.com [10.21.80.138]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79MD0IZ005106; Wed, 9 Aug 2006 15:13:00 -0700 (PDT) In-Reply-To: <018201c6bbfc$d3ee7290$b7c8000a@acmepacket.com> References: <018201c6bbfc$d3ee7290$b7c8000a@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 15:12:53 -0700 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=3161; t=1155161580; x=1156025580; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=NNXkIQlFo77oy96r2McZ3ySWqviJg5FVouMJ8c1oCLFzwa90Dc/6KMRyAB8bf/DDGONQbiei GX9lKdI53ZBc1E/jN+TMJLFAKudFgnIcnIk9b/Or6j+KdeFGW7udWM7p; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think Bob's proposal probably addresses your concerns and ends up being a better proposal than the one I made. On Aug 9, 2006, at 2:43 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> >> What I was trying to accomplish here was a solution that: >> >> 1) you don't send a STUN request until you receive a successful >> response to the register, this lets you know the device you are about >> to send a stun request to is "up" >> >> 2) you send a small number of stun requests and if you don't get any >> response, then you conclude that the server does not support stun and >> you stop stunning it >> >> As I mention on another email in this thread, I don't think it will >> be practical to blacklist an IP after a single stun packet so I think >> this solution could probably work. > > It won't be one single stun, as the UAC has to resend several in > case of > packet loss. Yes - I put "a small number" you put "several". I expect that we agree that we are probably talking a number between 3 and 5. > In my opinion blacklisting it may actually be the right thing > to do, oddly enough. But that's not my concern. > > My concerns/issues are: > > (1) A way to let the operator of the proxy know something's amiss and > correct it. That is more likely with a proxy-require sip-stun > option tag, > because a proxy which does not understand outbound would > (hopefully) log > this required thing it doesn't support, and the operator can simply > google > "sip-stun" and find this RFC. (I know, that's a simplistic view) This fits my mental model on how many voip networks are debugged :-) Many proxies also log that they received an malformed message too. > > (2) this is a mechanism which REQUIRES a proxy to do something, to > work > correctly, but doesn't want to use the SIP-defined mechanism to do > so. Why? > Every other extension has a ACK/NACK mechanism in SIP, except for > the one > that is arguably one of the biggest changes. > > (3) checking a server supports a malformed message by actually > sending the > malformed message is, well, simply rude. :) It makes this draft a new > torture test; as I said in Montreal I doubt any maker of SIP > products on > this mailing list or WG would have a problem with stun messages. > (though one > would have thought that back when Protos first came out, too) I don't think this is quite a fair characterization. If you set up your DNS such that the SIP SRV points at your imap server, you have the same problem. If I type the address and port of my web server in as the address of my sip server on my UA I have the same problem. In general the way nearly every IETF protocol in existence works is when it is given a servers address to connect to, it sends a message to it and sees if it works. > > -hadriel > p.s. Fredrik: yes, round and round we go. I think Bob's proposal could get us all off this merry go round - have a look and see if you could "live with it" even if it was not your first choice. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 18:16:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwKH-0002Va-PQ; Wed, 09 Aug 2006 18:14:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwKG-0002VV-Vp for sip@ietf.org; Wed, 09 Aug 2006 18:14:56 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAwKF-0002TF-Ne for sip@ietf.org; Wed, 09 Aug 2006 18:14:56 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 09 Aug 2006 15:14:55 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="1845724212:sNHT25838028" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79MEt6H018357; Wed, 9 Aug 2006 15:14:55 -0700 Received: from [192.168.1.2] (sjc-vpn4-138.cisco.com [10.21.80.138]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79MEsIZ006111; Wed, 9 Aug 2006 15:14:54 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1302@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F1302@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - using Path/Supported to indicate STUN keepalive support Date: Wed, 9 Aug 2006 15:14:47 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=406; t=1155161695; x=1156025695; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20-=20using= 20Path/Supported=20to=20indicate=20STUN=20keepalive=20support; X=v=3Dcisco.com=3B=20h=3DxSsL/IOx/c4tMJsB+A1LU1y0e/I=3D; b=fMBzpou0MpfbHR+gmt9MmfvNT30UP+DGX2FFZOjzxu1CcPz4va/ssyKO3zDQ9ynPc5JV2rK1 mns28FXEMDdVYe2wlYLtS59NmO74EWlGemZ3+nmUKD2U1s4A7EeRo9wM; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: IETF SIP List , Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 1:07 PM, Christer Holmberg ((JO/LMF)) wrote: > And, if we change "keepalive=stun" to something which also fits the > option-tag syntax we could use the same value in both > the Path and Supported header. It used to be sip-stun but there was strong agreement in one of the WG meetings to change it to keepalive=stun. we could reopen that decision too if folks wanted :-) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 18:47:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwnc-0008SV-0B; Wed, 09 Aug 2006 18:45:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwna-0008SQ-Ga for sip@ietf.org; Wed, 09 Aug 2006 18:45:14 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAwnZ-0006eW-8r for sip@ietf.org; Wed, 09 Aug 2006 18:45:14 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20060809224511m14000bj60e>; Wed, 9 Aug 2006 22:45:12 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k79MjAeY007716 for ; Wed, 9 Aug 2006 18:45:10 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k79MjAAw007712; Wed, 9 Aug 2006 18:45:10 -0400 Date: Wed, 9 Aug 2006 18:45:10 -0400 Message-Id: <200608092245.k79MjAAw007712@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <6B3E29721F78364AA2C43697AFB15D91038F6A@sonusmail07.sonusnet.com> (rmolodyko@sonusnet.com) Subject: Re: [Sip] Undefined UAS behaviour in RFC3261 12.2.2 References: <6B3E29721F78364AA2C43697AFB15D91038F6A@sonusmail07.sonusnet.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Molodyko, Rostislav" Not clear what UAS behaviour should be if the sequence number is equal to the remote sequence number, but the incoming request is a new request (not a retransmission). The only way this could happen is if the UAC is grossly malfunctioning and sending more than one request with the same Call-Id/CSeq. (Notice that the other cases can happen normally, due to network delays, etc.) If the UAS notices the problem, it can reject the request with 500. But it is not required to detect the problem, it might just re-send the response to the first request. Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 18:50:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwqX-0002UR-00; Wed, 09 Aug 2006 18:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwqV-0002UM-GB for sip@ietf.org; Wed, 09 Aug 2006 18:48:15 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAwqT-00079z-7D for sip@ietf.org; Wed, 09 Aug 2006 18:48:15 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A62C0234; Wed, 09 Aug 2006 18:48:12 -0400 From: "Hadriel Kaplan" To: "'Cullen Jennings'" Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 18:48:12 -0400 Message-ID: <01a401c6bc05$e4e8d3c0$b7c8000a@acmepacket.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.2869 Thread-Index: Aca8APouEYFzx3rSSBCm7wodrqt3PAAAkVBg X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > > (1) A way to let the operator of the proxy know something's amiss and > > correct it. That is more likely with a proxy-require sip-stun > > option tag, > > because a proxy which does not understand outbound would > > (hopefully) log > > this required thing it doesn't support, and the operator can simply > > google > > "sip-stun" and find this RFC. (I know, that's a simplistic view) > This fits my mental model on how many voip networks are debugged :-) > Many proxies also log that they received an malformed message too. Totally, but I would think it's a lot harder to know what it means when your proxy says "I got a malformed message" or even if it gave you a copy of it, since it and you don't know it's a stun message. Now if they had only made the STUN message format start with 0x5354554E, it would help. ;-) > > (3) checking a server supports a malformed message by actually > > sending the > > malformed message is, well, simply rude. :) It makes this draft a new > > torture test; as I said in Montreal I doubt any maker of SIP > > products on > > this mailing list or WG would have a problem with stun messages. > > (though one > > would have thought that back when Protos first came out, too) > > I don't think this is quite a fair characterization. If you set up > your DNS such that the SIP SRV points at your imap server, you have > the same problem. If I type the address and port of my web server in > as the address of my sip server on my UA I have the same problem. In > general the way nearly every IETF protocol in existence works is when > it is given a servers address to connect to, it sends a message to it > and sees if it works. Yes, but what IETF RFC would actually mandate you to send SIP to your IMAP server, to see if the IMAP server also understands SIP? A mis-configuration or user error is a very different context, I think. For example, in one you blame the operator of the DNS, and in the other you blame the IETF. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 18:58:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwyU-0001m2-JD; Wed, 09 Aug 2006 18:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwyT-0001lx-4J for sip@ietf.org; Wed, 09 Aug 2006 18:56:29 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAwyQ-00084k-Kd for sip@ietf.org; Wed, 09 Aug 2006 18:56:29 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k79MuEF14092; Wed, 9 Aug 2006 15:56:15 -0700 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F12F7@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F12F7@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <836b512099bc8be1f49ca0fc417e7ddf@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 15:56:41 -0700 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Did you read the slides? The topic of this thread is only slides 3 and 4. thanks, -rohan On Aug 9, 2006, at 8:44, Christer Holmberg ((JO/LMF)) wrote: > > Hi Rohan, > > Isn't STUN usage for IP port/discovery (as mentioned by Hisham) off > topic? > > Regards, > > Christer > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com] > Sent: 9. elokuuta 2006 18:42 > To: Christer Holmberg (JO/LMF) > Cc: Hisham Khartabil; Rohan Mahy; IETF SIP List > Subject: Re: [Sip] Outbound Issues: slides 3 and 4 > > Hi Christer, > > I think your question is off topic for this thread. Are you asking > about "Outbound Issues: slide 7"? > > I think the answer to your question is no, but I'm not 100% sure what > you are asking. > > thanks, > -rohan > > > On Aug 9, 2006, at 8:06, Christer Holmberg ((JO/LMF)) wrote: > >> >> Hi, >> >>> I don't like this proposal. I'm still with the camp that says: if >> configured, then it must be true. >>> >>> My main objection is that in this proposal, you are required to send >> SIP messages before STUN messages. That's a mandate >>> that I'm not comfortable with since I might want to send STUN first >>> to >> discover my public IP/port to populate the contact >>> header before I send the first REGISTER. >> >> Is the public IP/port discovery part of the STUN usage for keep-alive? >> >> Regards, >> >> Christer >> >> >> >> >>> >>> We had a very long discussion in Montreal about discovery and >>> validation of a SIP outbound proxy server's ability to receive STUN >>> requests. While the vast majority of the room was comfortable that >>> "keepalive=stun" in a URI was a sufficient indicator that an outbound > >>> proxy supports SIP and STUN over the same port, a small but extremely > >>> vocal minority had significant problems with this assumption. After >>> a >> >>> discussion with Dean, I am willing to try a validation proposal which > >>> adds no extra round trips if the SIP UA was indeed correctly >>> configured. >>> >>> The specific proposal works like this. A UAC which has an outbound >>> URI indicating with ;keepalive=stun that the next hop can support >>> STUN >> >>> messages on the SIP port, needs to verify the first hop supports STUN > >>> before sending any STUN messages. The UAC sends its first SIP message > >>> to the next hop with a Proxy-Require: sip-stun. If the URI was >>> correct (STUN was supported), and the first-hop is an intermediary, >>> the first-hop removes the Proxy-Require and forwards the SIP request >>> (probably a REGISTER request) along adding no additional delay. A >>> positive response to a REGISTER or OPTIONS with Supported: outbound >>> and no error counts as positive confirmation that either the >>> registrar >> >>> supports STUN or expects to never receive a request without getting >>> it >> >>> from an outbound proxy which did not complain about the Proxy-Require > >>> [1]. If the UAC was misconfigured (the first-hop intermediary does >>> not >> >>> support STUN keepalives), either the first hop will reject the SIP >>> request (if it is an intermediary), or the registrar will not include > >>> an indicator that it supports outbound (if the first hop was the >>> registrar). >>> >>> Note that this proposal is not a full *discovery* mechanism, just a >>> verification mechanism. For example, if the registrar doesn't >>> support >> >>> outbound, but the first-hop does, there is no way described here to >>> discover that the first-hop can accept STUN keepalives. Do not >>> confuse support of STUN with support of outbound. Supported: >>> outbound >> >>> implies that the registrar supports STUN or is configured to use an >>> outbound proxy that does. The sip-stun option tag only means that >>> you >> >>> can send and receive STUN requests on your SIP port. While outbound >>> requires STUN, STUN does not require outbound. >>> >>> [1] Also Note that there is a caveat that you can still shoot >>> yourself >> >>> in the foot if you allow messages to come straight to your registrar >>> that does not support STUN. I think we agreed that we are not going >>> to enumerate all the ways you can subtly break things in SIP though. >>> >>> thanks, >>> -rohan >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 19:00:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAx0O-0002wi-Ah; Wed, 09 Aug 2006 18:58:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAx0N-0002tp-E3 for sip@ietf.org; Wed, 09 Aug 2006 18:58:27 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAx0K-0008LB-VG for sip@ietf.org; Wed, 09 Aug 2006 18:58:27 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2006 15:58:25 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="310813777:sNHT27708660" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79MwOcU023018; Wed, 9 Aug 2006 15:58:24 -0700 Received: from [192.168.1.2] (sjc-vpn4-138.cisco.com [10.21.80.138]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k79MwNuD028433; Wed, 9 Aug 2006 15:58:23 -0700 (PDT) In-Reply-To: <1155070150.14419.18.camel@macbuster.research.nokia.com> References: <1155070150.14419.18.camel@macbuster.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3135FE06-4196-44A4-9310-0AFEF22E449D@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound Date: Wed, 9 Aug 2006 15:58:16 -0700 To: Aki Niemi X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=4007; t=1155164304; x=1156028304; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Question=20regarding=20instance=20ID=20in=20GRUU=20and=2 0outbound; X=v=3Dcisco.com=3B=20h=3DIENY9UeXpCdBpVOdSBMqVoWwwaY=3D; b=jQeIr66XOLrlFbbIv5cNMDuo0pAGV0s53ukX4Cf66vx70qzvGZZb+vjmNUwdoE7yqSxSFru7 FJyTHO9/GpOxki/T5YP8wgnpfF30oI/mE563TdXPJ1bPEbOGDl/tL6iT; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This email is sort of irrelevant but I'm sending it anyways :-) A few year back, I wrote http://www.softarmor.com/wgdb/docs/draft-jennings-sipping-instance- id-00.txt and it had some use cases for why one might need a long term stable identifier for a device. I think theses still hold. We need something and it needs to survive reboots of a device. You are right it does not matter who generates the ID but the UA needs to store it. Cookies were discussed but rejected due to worries about if there was AT&T IPR on them. I originally proposed something "simple" to generate - I'm a big fan of large random numbers. Others were less comfortable with large random numbers and wanted something algorithmically guaranteed to be unique by some sort of delegated assignment - like MAC or OIDs. Most devices had MAC addresses or an equivalent sort of identifier. I wrote something for MAC plus something for things without a MAC. It was looking less simple. There were problems with the multiple phones on one MAC that added more complexity. Pretty soon, I was reinventing UUID. UUID covered everything we needed and encompassed a huge set of existing arguments on the subject. If you remove any part of UUID, there is some use case that gets broken. It may be that the use case is bogus but none the less the argument goes on. Anyways, I think we needs something and I can't imagine anything much simpler than what we have right now. On Aug 8, 2006, at 1:49 PM, Aki Niemi wrote: > Howdy, > > I read GRUU and outbound, and an old nagging concern of mine > resurfaced: > what the heck do we need the instance ID for? > > Seems outbound uses it to guarantee uniqueness of flows in a > registrar, > but to me it sounds weird that the task of acquiring unique IDs within > the registrar's internal state is left to the UA -- after all, > browsers > don't generally generate cookies themselves but store whatever the > website gives them. > > To me, a much better approach would be to have the registrar generate > and allocate a unique ID (perhaps the 'opaque' used in GRUU?) for the > first REGISTER, and whenever a client registers with that ID again, it > is deemed the same UA. A REGISTER without an ID would be another UA > instance. > > Even DHCP clients' leases seem to survive reboots without some > weird URN > generation, so I don't think that it's unreasonable to require UAs to > store their outbound IDs either. I mean, they already have to store > the > reg-id, no? (Not to mention web cookies...) Side issue but I think they would usually just hardcode in reg-id of 1 for the first one, 2 for second and so on. Some devices store only their MAC and the configuration system uses that to know what data to hand down to them. I have seen some systems where the config handed to the phone is based only on the which ethernet port in the switch the device was connected to. Some residential ethernet to the home systems do this so that if my neighbor plugs in his phone at my house, it becomes my phone. In theory these systems would not need to really store anything. > > And worst case is you need to garbage-collect some stale flows, in > case > a UA happens to forget its ID, but that you need to be doing in any > case. > > We chose a similar approach over instance ID in PUBLISH, which uses > etags generated by the server to identify uniqueness of publisher > instances. With PUBLISH, UAs are also instructed to remember their > etags, even across reboots. of course close to none of them do :-) > > Cheers, > Aki > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 19:01:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAx1P-00044K-Bd; Wed, 09 Aug 2006 18:59:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAx1O-00040P-2A for sip@ietf.org; Wed, 09 Aug 2006 18:59:30 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAx1M-0008R8-K8 for sip@ietf.org; Wed, 09 Aug 2006 18:59:30 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k79MxLF14132; Wed, 9 Aug 2006 15:59:22 -0700 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F12F9@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F12F9@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4f5fcd71a3d041f4ae2e35ccfae25c37@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound issues: slides 9 and 10 - Why does every proxy need to support outbound? Date: Wed, 9 Aug 2006 15:59:30 -0700 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, please read the slides. The issue we are trying to detect is described in slide 9. The UA sends through an outbound-proxy that adds a Path, but does not support outbound. The registrar needs to detect that. thanks, -rohan On Aug 9, 2006, at 9:46, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > A couple of questions: > >> The issues on slide 9 (how does a registrar verify that an edge proxy > supports outbound) and slide 10 (what does >"Supported: outbound" mean) > deal with detecting that all the required hops support outbound. Slide >> 9 specifically uncovered a problem with outbound proxies that add a > Path URI but don't include a flow token. >> >> The proposed solution is as follows. If a proxy inserts a Path header > with a flow token consistent with the rules d >> escribed in outbound, it MUST add the ;ob parameter to the proxy URI > that has the flow token. >> >> The registrar verifies that any Path header URIs contain the ;ob > parameter. If there are any Path URIs without the ob >> parameter, the registrar does not return Supported: outbound. > > [CHH] Why would every Path header need to contain the ;ob parameter? > The > REGISTER request may traverse, in addition to the outbound proxy, > multiple proxies which insert a Path header. Do all these proxies > really > need to support outbound? > >> Furthermore, the registrar needs to check that the first hop after the > UAC is represented in the Path list (unless the >> registrar recognizes that the first hop after the UAC is in the same > domain and doesn't need to include Path URIs with a >> flow token). Note that this implies that whatever the proxy puts in > the Via (IP address or FQDN), it must put the same >> hostname in the Path header (but there is no need for a complete URI > comparison). If the first hop is not correctly >> represented, the registrar ignores the reg-id parameter and does not > return Supported: outbound. > > [CHH] Isn't it much easier to mandate the outbound proxy to always > insert a Path header? > > OR, another possibility is that the outbound proxy, if it detects that > the UAC supports outbound, insert some option-tag of itself in the > Supported header, to indicate to the registrar that it supports > outbound. Then the registrar does not need start looking at the Path > headers. > > Regards, > > Christer > > > > > > > > > The implication of this is that an outbound-proxy that supports > outbound > needs to support Path and flow tokens for registrations to all foreign > domains. Inside the same domain, the first-hop proxy and the registrar > can still use Path to communicate with each other, but they can use > some > other private mechanism to disaggregate this functionality. > > thanks, > -rohan > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 09 19:23:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAxN7-0003SB-0D; Wed, 09 Aug 2006 19:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAxN5-0003S6-Cj for sip@ietf.org; Wed, 09 Aug 2006 19:21:55 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAxN4-0003CU-4d for sip@ietf.org; Wed, 09 Aug 2006 19:21:55 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id AE110144; Wed, 09 Aug 2006 19:21:53 -0400 From: "Hadriel Kaplan" To: "'Cullen Jennings'" Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Wed, 9 Aug 2006 19:21:53 -0400 Message-ID: <01a501c6bc0a$99722f90$b7c8000a@acmepacket.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.2869 Thread-Index: Aca8APouEYFzx3rSSBCm7wodrqt3PAABQ/yA X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, August 09, 2006 6:13 PM > To: Hadriel Kaplan > Cc: 'IETF SIP List' > Subject: Re: [Sip] Outbound Issues: slides 3 and 4 > > > I think Bob's proposal probably addresses your concerns and ends up > being a better proposal than the one I made. > > I think Bob's proposal could get us all off this merry go round - > have a look and see if you could "live with it" even if it was not > your first choice. I would if I knew which one it was. :) Is it: (1) If auto-config or auto-discovery doesn't indicate the proxy supports stun, then the UA MUST use Options, with the proxy's address as the request-uri, to verify the proxy supports STUN by checking that the proxy inserted a sip-stun option tag. (where would it stick this tag, BTW?) That's your proposal isn't it? Or (2) If auto-config or auto-discovery doesn't indicate the proxy supports stun, then the UA MUST verify the proxy supports stun by inserting a proxy-require sip-stun option tag, which the proxy will remove and continue to process if it supports stun, or respond negatively with a 420 Bad Extension if it does not. I am assuming here auto-config means any way of being configured EXCEPT through a user interface? And auto-discovery is Erkki's draft, or something similar? I _really_ prefer (2) because it's simpler, and I find simpler gets implemented. And tying the success/fail of a registration process to Options seems bad to me, though I can't put my finger on why. But yeah I can live with it. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 22:47:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB0Y2-0005f1-97; Wed, 09 Aug 2006 22:45:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB0Xz-0005di-8t for sip@ietf.org; Wed, 09 Aug 2006 22:45:23 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB0Xw-0000tU-Ol for sip@ietf.org; Wed, 09 Aug 2006 22:45:23 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3R004O3HF041@szxga03-in.huawei.com> for sip@ietf.org; Thu, 10 Aug 2006 10:54:36 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3R00FT5HEZNZ@szxga03-in.huawei.com> for sip@ietf.org; Thu, 10 Aug 2006 10:54:36 +0800 (CST) Received: from k19120I ([10.70.145.109]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3R009O2H3QVC@szxml03-in.huawei.com> for sip@ietf.org; Thu, 10 Aug 2006 10:47:50 +0800 (CST) Date: Thu, 10 Aug 2006 10:44:23 +0800 From: Manjunath Warad Subject: RE: [Sip] Undefined UAS behaviour in RFC3261 12.2.2 In-reply-to: <6B3E29721F78364AA2C43697AFB15D91038F6A@sonusmail07.sonusnet.com> To: "'Molodyko, Rostislav'" , sip@ietf.org Message-id: <003701c6bc26$e32c0590$6d91460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2012384296==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2012384296== Content-type: multipart/alternative; boundary="Boundary_(ID_VyDrYNgzFkC1paVIkJal0w)" This is a multi-part message in MIME format. --Boundary_(ID_VyDrYNgzFkC1paVIkJal0w) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi, I think UAS need to treat it as normal request though CSeq is same. I would like to quote a scenario where this could be possible! Since proxy can retry request on failure response, if UAS rejected a request with failure response and immediate upstream proxy retries to the same UAS and since proxy cannot update CSeq, this scenario is quite possible in the network. Retrying to the same UAS mean to say, the same UA stack might be shared among different users and CSeq check would matter for UA stack and not the user of UA. Could be something like this: UAC P1 P2 P3 UAS(stack) User1 User2 INV --------------> ----------------> -------------> ---------------> -------------------> <---------------- <---------------4xx INV(retry)------> ----------------------------------------> Now CSeq at UAS is same. <---------------- <---------------------------------------200 <--------------- <--------------- 200<-------------- Rgds, Manju -----Original Message----- From: Molodyko, Rostislav [mailto:rmolodyko@sonusnet.com] Sent: Thursday, August 10, 2006 6:01 AM To: sip@ietf.org Subject: [Sip] Undefined UAS behaviour in RFC3261 12.2.2 Hi All, The section 12.2.2 "UAS Behavior" states that UAS should : - reject the requests "If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number" - consider the request in-order if "the sequence number of the request is greater than the remote sequence number" Not clear what UAS behaviour should be if the sequence number is equal to the remote sequence number, but the incoming request is a new request (not a retransmission). In the example below UAC sends UPDATE with the same Cseq like PRACK. I guess UAS should reject that UPDATE with 500 or 4xx, while it is not stated in RFC. At UAC side: ============ TRANSMITTED: ========= INVITE sip:6667171111@10.13.15.107:4000 SIP/2.0 Call-ID: 4317683@10.7.6.40 CSeq: 10 INVITE ... ============ RECEIVED: ========== SIP/2.0 180 Ringing Call-ID: 4317683@10.7.6.40 CSeq: 10 INVITE ============ TRANSMITTED: ========= PRACK sip:6667171111@10.13.15.107:4000 SIP/2.0 Call-ID: 4317683@10.7.6.40 CSeq: 11 PRACK ... ============ RECEIVED: ========== SIP/2.0 200 OK Call-ID: 4317683@10.7.6.40 CSeq: 11 PRACK ============ TRANSMITTED: ========= UPDATE sip:6667171111@10.13.15.107:4000 SIP/2.0 Call-ID: 4317683@10.7.6.40 CSeq: 11 UPDATE ... ============ RECEIVED: ========== SIP/2.0 200 OK // ??? Call-ID: 4317683@10.7.6.40 CSeq: 11 UPDATE Is this case covered by any new RFC or Draft? Regards, Ros Molodyko SIP Development Sonus Networks 250 Apollo Drive Chelmsford, MA 01824 Direct phone: 978-614-8620 --Boundary_(ID_VyDrYNgzFkC1paVIkJal0w) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT Message
Hi,
    I think UAS need to treat it as normal request though CSeq is same. I would like to quote a scenario where this could be possible! Since proxy can retry request on failure response, if UAS rejected a request with failure response and immediate upstream proxy retries to the same UAS and since proxy cannot update CSeq, this scenario is quite possible in the network.
    Retrying to the same UAS mean to say, the same UA stack might be shared among different users and CSeq check would matter for UA stack and not the user of UA.
 
Could be something like this:
 
UAC                P1                P2                P3                UAS(stack)            User1                User2
INV -------------->
                        ---------------->
                                            ------------->
                                                                ---------------> ------------------->
                                                                <---------------- <---------------4xx
                                                                INV(retry)------> ----------------------------------------> 
                                                                       Now CSeq at UAS is same.
                                                                <---------------- <---------------------------------------200
                                            <---------------
                        <---------------
200<--------------
 
Rgds,
Manju
 
-----Original Message-----
From: Molodyko, Rostislav [mailto:rmolodyko@sonusnet.com]
Sent: Thursday, August 10, 2006 6:01 AM
To: sip@ietf.org
Subject: [Sip] Undefined UAS behaviour in RFC3261 12.2.2

Hi All,

        The section 12.2.2 “UAS Behavior” states that UAS should :

-       reject the requests “If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number”

-       consider the request in-order if “the sequence number of the request is greater than the remote sequence number”

      Not clear what UAS behaviour should be if the sequence number is equal to the remote sequence number, but the incoming request is a new request (not a retransmission).

        In the example below UAC sends UPDATE with the same Cseq like PRACK. I guess UAS should reject that UPDATE with 500 or 4xx, while it is not stated in RFC.

At UAC side:

============ TRANSMITTED: =========

INVITE sip:6667171111@10.13.15.107:4000 SIP/2.0

Call-ID: 4317683@10.7.6.40

CSeq: 10 INVITE

...

============ RECEIVED: ==========

SIP/2.0 180 Ringing

Call-ID: 4317683@10.7.6.40

CSeq: 10 INVITE

============ TRANSMITTED: =========

PRACK sip:6667171111@10.13.15.107:4000 SIP/2.0

Call-ID: 4317683@10.7.6.40

CSeq: 11 PRACK

...

============ RECEIVED: ==========

SIP/2.0 200 OK

Call-ID: 4317683@10.7.6.40

CSeq: 11 PRACK

============ TRANSMITTED: =========

UPDATE sip:6667171111@10.13.15.107:4000 SIP/2.0

Call-ID: 4317683@10.7.6.40

CSeq: 11 UPDATE

...

============ RECEIVED: ==========

SIP/2.0 200 OK                          // ???

Call-ID: 4317683@10.7.6.40

CSeq: 11 UPDATE

        Is this case covered by any new RFC or Draft?

Regards,

Ros Molodyko

SIP Development

Sonus Networks

250 Apollo Drive

Chelmsford, MA 01824

Direct phone: 978-614-8620

 

--Boundary_(ID_VyDrYNgzFkC1paVIkJal0w)-- --===============2012384296== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============2012384296==-- From sip-bounces@ietf.org Wed Aug 09 23:04:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB0p2-00026Z-GR; Wed, 09 Aug 2006 23:03:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB0p1-00026U-Li for sip@ietf.org; Wed, 09 Aug 2006 23:02:59 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB0p0-0001YG-Cx for sip@ietf.org; Wed, 09 Aug 2006 23:02:59 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20060810030247m1400094tne>; Thu, 10 Aug 2006 03:02:57 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k7A32keY013579 for ; Wed, 9 Aug 2006 23:02:46 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k7A32ks7013575; Wed, 9 Aug 2006 23:02:46 -0400 Date: Wed, 9 Aug 2006 23:02:46 -0400 Message-Id: <200608100302.k7A32ks7013575@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <3135FE06-4196-44A4-9310-0AFEF22E449D@cisco.com> (fluffy@cisco.com) Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <3135FE06-4196-44A4-9310-0AFEF22E449D@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Cullen Jennings I originally proposed something "simple" to generate - I'm a big fan of large random numbers. Others were less comfortable with large random numbers and wanted something algorithmically guaranteed to be unique by some sort of delegated assignment - like MAC or OIDs. Most devices had MAC addresses or an equivalent sort of identifier. I wrote something for MAC plus something for things without a MAC. It was looking less simple. There were problems with the multiple phones on one MAC that added more complexity. Pretty soon, I was reinventing UUID. UUID covered everything we needed and encompassed a huge set of existing arguments on the subject. If you remove any part of UUID, there is some use case that gets broken. It may be that the use case is bogus but none the less the argument goes on. Anyways, I think we needs something and I can't imagine anything much simpler than what we have right now. Let me suggest that the current concept (a URN as an instance ID) is (from the point of view of the protocol) as simple as UUIDs, but more general, and covers cases that UUIDs cannot: - If you have a MAC address, you can package that into a UUID, which can be made into a URN. - If you choose a big random number, you can package that into a UUID, which can be made into a URN. - If you want delegated assignment, you can assign an OID, which can be made into a URN. While leaving the essentials of the mechanism (and its minimal implementations) quite simple, it allows alternative methods that cover every use case anyone has thought of. There is a certain overhead for forcing the UA to choose/have a URN, but IMHO it's less than the protocol complications of having a registrar hand them out. (Especially the failure cases.) Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 09 23:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB1cb-0004Tb-N2; Wed, 09 Aug 2006 23:54:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB1ca-0004TW-OJ for sip@ietf.org; Wed, 09 Aug 2006 23:54:12 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB1cX-0003Rf-PN for sip@ietf.org; Wed, 09 Aug 2006 23:54:12 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7D5AF8E0002; Thu, 10 Aug 2006 05:54:08 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 05:54:07 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 05:54: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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Thu, 10 Aug 2006 05:54:05 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1305@esealmw113.eemea.ericsson.se> In-Reply-To: <836b512099bc8be1f49ca0fc417e7ddf@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca8BxCQCDVHhTiHQTGj9TulHaNqYwAKXAEw From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 10 Aug 2006 03:54:06.0814 (UTC) FILETIME=[A0C1B7E0:01C6BC30] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, I agree it's out of scope - I was just replying to Hisham's comment. Regards, Christer=20 -----Original Message----- From: Rohan Mahy [mailto:rohan@ekabal.com]=20 Sent: 10. elokuuta 2006 1:57 To: Christer Holmberg (JO/LMF) Cc: Hisham Khartabil; Rohan Mahy; IETF SIP List Subject: Re: [Sip] Outbound Issues: slides 3 and 4=20 Did you read the slides? The topic of this thread is only slides 3 and 4. thanks, -rohan On Aug 9, 2006, at 8:44, Christer Holmberg ((JO/LMF)) wrote: > > Hi Rohan, > > Isn't STUN usage for IP port/discovery (as mentioned by Hisham) off=20 > topic? > > Regards, > > Christer > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com] > Sent: 9. elokuuta 2006 18:42 > To: Christer Holmberg (JO/LMF) > Cc: Hisham Khartabil; Rohan Mahy; IETF SIP List > Subject: Re: [Sip] Outbound Issues: slides 3 and 4 > > Hi Christer, > > I think your question is off topic for this thread. Are you asking=20 > about "Outbound Issues: slide 7"? > > I think the answer to your question is no, but I'm not 100% sure what=20 > you are asking. > > thanks, > -rohan > > > On Aug 9, 2006, at 8:06, Christer Holmberg ((JO/LMF)) wrote: > >> >> Hi, >> >>> I don't like this proposal. I'm still with the camp that says: if >> configured, then it must be true. >>> >>> My main objection is that in this proposal, you are required to send >> SIP messages before STUN messages. That's a mandate >>> that I'm not comfortable with since I might want to send STUN first=20 >>> to >> discover my public IP/port to populate the contact >>> header before I send the first REGISTER. >> >> Is the public IP/port discovery part of the STUN usage for keep-alive? >> >> Regards, >> >> Christer >> >> >> >> >>> >>> We had a very long discussion in Montreal about discovery and=20 >>> validation of a SIP outbound proxy server's ability to receive STUN=20 >>> requests. While the vast majority of the room was comfortable that=20 >>> "keepalive=3Dstun" in a URI was a sufficient indicator that an=20 >>> outbound > >>> proxy supports SIP and STUN over the same port, a small but=20 >>> extremely > >>> vocal minority had significant problems with this assumption. After >>> a >> >>> discussion with Dean, I am willing to try a validation proposal=20 >>> which > >>> adds no extra round trips if the SIP UA was indeed correctly=20 >>> configured. >>> >>> The specific proposal works like this. A UAC which has an outbound=20 >>> URI indicating with ;keepalive=3Dstun that the next hop can support=20 >>> STUN >> >>> messages on the SIP port, needs to verify the first hop supports=20 >>> STUN > >>> before sending any STUN messages. The UAC sends its first SIP=20 >>> message > >>> to the next hop with a Proxy-Require: sip-stun. If the URI was=20 >>> correct (STUN was supported), and the first-hop is an intermediary,=20 >>> the first-hop removes the Proxy-Require and forwards the SIP request >>> (probably a REGISTER request) along adding no additional delay. A=20 >>> positive response to a REGISTER or OPTIONS with Supported: outbound=20 >>> and no error counts as positive confirmation that either the=20 >>> registrar >> >>> supports STUN or expects to never receive a request without getting=20 >>> it >> >>> from an outbound proxy which did not complain about the=20 >>> Proxy-Require > >>> [1]. If the UAC was misconfigured (the first-hop intermediary does=20 >>> not >> >>> support STUN keepalives), either the first hop will reject the SIP=20 >>> request (if it is an intermediary), or the registrar will not=20 >>> include > >>> an indicator that it supports outbound (if the first hop was the=20 >>> registrar). >>> >>> Note that this proposal is not a full *discovery* mechanism, just a=20 >>> verification mechanism. For example, if the registrar doesn't=20 >>> support >> >>> outbound, but the first-hop does, there is no way described here to=20 >>> discover that the first-hop can accept STUN keepalives. Do not=20 >>> confuse support of STUN with support of outbound. Supported: >>> outbound >> >>> implies that the registrar supports STUN or is configured to use an=20 >>> outbound proxy that does. The sip-stun option tag only means that=20 >>> you >> >>> can send and receive STUN requests on your SIP port. While outbound=20 >>> requires STUN, STUN does not require outbound. >>> >>> [1] Also Note that there is a caveat that you can still shoot=20 >>> yourself >> >>> in the foot if you allow messages to come straight to your registrar >>> that does not support STUN. I think we agreed that we are not going >>> to enumerate all the ways you can subtly break things in SIP though. >>> >>> thanks, >>> -rohan >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.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 >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 00:18:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB1yN-0004XM-57; Thu, 10 Aug 2006 00:16:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB1yM-0004X4-8r for sip@ietf.org; Thu, 10 Aug 2006 00:16:42 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB1yK-0004N6-SM for sip@ietf.org; Thu, 10 Aug 2006 00:16:42 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2006 21:16:40 -0700 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.20060308/8.12.11) with ESMTP id k7A4GeYH014460; Wed, 9 Aug 2006 21:16:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7A4Gebb006941; Wed, 9 Aug 2006 21:16:40 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 21:16:39 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.106]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 21:16:39 -0700 Message-Id: <4.3.2.7.2.20060809231139.0294ddf8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Aug 2006 23:16:38 -0500 To: "Molodyko, Rostislav" , From: "James M. Polk" Subject: Re: [Sip] Undefined UAS behaviour in RFC3261 12.2.2 In-Reply-To: <6B3E29721F78364AA2C43697AFB15D91038F6A@sonusmail07.sonusne t.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Aug 2006 04:16:39.0396 (UTC) FILETIME=[C6F55A40:01C6BC33] DKIM-Signature: a=rsa-sha1; q=dns; l=2852; t=1155183400; x=1156047400; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20Undefined=20UAS=20behaviour=20in=20RFC3261=2012.2.2; X=v=3Dcisco.com=3B=20h=3DgAlXUl51WggMhaCz7qtWDTro+bA=3D; b=Bkcgp6nKYFtAj7uGpRqPY6Pvdqt7vgD6qzEMWHJVzXGWeukO1LE7HQM8L7nzHuQIAqYabRLY G7rYMragZqEAmHEf/dL+prsjxE7t8Cg+bX1LAMcLzV1SQkXmEG/50dOt; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ros CSEq numbers are independent between Methods. In other words, the PRACK and UPDATE can be using the same CSeq numbers, which have to always increase by 1 within a new transaction of that Method regardless who the UAS is (retransmissions have the same CSeq number as the original request). Therefore you would not get an error unless a new request had the same Cseq number using the same Method *or* a new request or retransmission used a lower number than any previous transaction used within that same Method. At 06:01 PM 8/9/2006 -0400, Molodyko, Rostislav wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C6BBFF.5CE91767" > >Hi All, > > The section 12.2.2 UAS Behavior states that UAS should : > >- reject the requests If the remote sequence number was not empty, >but the sequence number of the request is lower than the remote sequence >number > >- consider the request in-order if the sequence number of the >request is greater than the remote sequence number >Not clear what UAS behaviour should be if the sequence number is equal to >the remote sequence number, but the incoming request is a new request (not >a retransmission). > > In the example below UAC sends UPDATE with the same Cseq like > PRACK. I guess UAS should reject that UPDATE with 500 or 4xx, while it is > not stated in RFC. > >At UAC side: > >============ TRANSMITTED: ========= > >INVITE sip:6667171111@10.13.15.107:4000 SIP/2.0 > >Call-ID: 4317683@10.7.6.40 > >CSeq: 10 INVITE > >... > >============ RECEIVED: ========== > >SIP/2.0 180 Ringing > >Call-ID: 4317683@10.7.6.40 > >CSeq: 10 INVITE > >============ TRANSMITTED: ========= > >PRACK sip:6667171111@10.13.15.107:4000 SIP/2.0 > >Call-ID: 4317683@10.7.6.40 > >CSeq: 11 PRACK > >... > >============ RECEIVED: ========== > >SIP/2.0 200 OK > >Call-ID: 4317683@10.7.6.40 > >CSeq: 11 PRACK > >============ TRANSMITTED: ========= > >UPDATE sip:6667171111@10.13.15.107:4000 SIP/2.0 > >Call-ID: 4317683@10.7.6.40 > >CSeq: 11 UPDATE > >... > >============ RECEIVED: ========== > >SIP/2.0 200 OK // ??? > >Call-ID: 4317683@10.7.6.40 > >CSeq: 11 UPDATE > > Is this case covered by any new RFC or Draft? > >Regards, > >Ros Molodyko > >SIP Development > >Sonus Networks > >250 Apollo Drive > >Chelmsford, MA 01824 > >Direct phone: 978-614-8620 > > > >_______________________________________________ >Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 00:26:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB25t-0002To-Uw; Thu, 10 Aug 2006 00:24:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB25r-0002Pb-Qp for sip@ietf.org; Thu, 10 Aug 2006 00:24:27 -0400 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB25q-0004hf-B6 for sip@ietf.org; Thu, 10 Aug 2006 00:24:27 -0400 Received: (from mail.tataelxsi.co.in [192.91.75.29]) by mail.tataelxsi.co.in (MOS 3.8.1-FCS) with HTTP/1.1 id BXY08641 (AUTH rathod); Thu, 10 Aug 2006 10:04:10 +0530 (IST) From: Rathod Subhashchandra To: sip@ietf.org X-Mailer: Mirapoint Webmail Direct 3.8.1-FCS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20060810100410.BXY08641@mail.tataelxsi.co.in> Date: Thu, 10 Aug 2006 10:04:10 +0530 (IST) X-Junkmail-Info: ALL_TRUSTED,NO_REAL_NAME X-Junkmail-Status: score=4/50, host=mail.tataelxsi.co.in X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] What makes PoC Client IMS compliant X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi All, I have developed a PoC client. I am asked that is it a IMS compliant? I don't know what IMS compliant means here. Can anyone help me understanding this question? Is it a valid question? Thanks in advance for a quick reply. Thanks ! Rathod. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 01:58:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3Wf-0007aG-KI; Thu, 10 Aug 2006 01:56:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3Wd-0007Z2-VV for sip@ietf.org; Thu, 10 Aug 2006 01:56:11 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB3Wa-0005x2-LB for sip@ietf.org; Thu, 10 Aug 2006 01:56:11 -0400 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7A5w8iW000991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Aug 2006 00:58:09 -0500 Message-ID: <44DACA71.8030601@softarmor.com> Date: Thu, 10 Aug 2006 00:56:01 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] Outbound Issues: slides 3 and 4 References: <5EB80D22825EEE42872083AD5BFFB594017F12F7@esealmw113.eemea.ericsson.se> <836b512099bc8be1f49ca0fc417e7ddf@ekabal.com> In-Reply-To: <836b512099bc8be1f49ca0fc417e7ddf@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: IETF SIP List , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan Mahy wrote: > Did you read the slides? The topic of this thread is only slides 3 and 4. > Dude, he's saying you should have yelled at Hisham for being off-topic. Bad Hisham! No biscuit! None for me either! -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 02:21:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3t6-0006rx-Ss; Thu, 10 Aug 2006 02:19:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3t4-0006ni-OD for sip@ietf.org; Thu, 10 Aug 2006 02:19:22 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB3t2-0002ol-R0 for sip@ietf.org; Thu, 10 Aug 2006 02:19:22 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EDDFB4F0008; Thu, 10 Aug 2006 08:19:19 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 08:19:19 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 08:19:19 +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 Subject: RE: [Sip] Outbound issues: slides 9 and 10 - Why does every proxy need to support outbound? Date: Thu, 10 Aug 2006 08:19:18 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1306@esealmw113.eemea.ericsson.se> In-Reply-To: <4f5fcd71a3d041f4ae2e35ccfae25c37@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound issues: slides 9 and 10 - Why does every proxy need to support outbound? Thread-Index: Aca8B3n1HkGJJ/VzQN6IzBu/MxYVuwAPKZxw From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 10 Aug 2006 06:19:19.0247 (UTC) FILETIME=[E9C57DF0:01C6BC44] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, >Christer, please read the slides. The issue we are trying to detect is described in slide 9. The UA sends through an=20 >outbound-proxy that adds a Path, but does not support outbound. The registrar needs to detect that. I am not arguing against that. I am simply commenting on the proposed mechanisms that YOU wrote. YOU said that ALL Path headers (not only the one inserted by the outbound proxy) must contain the ob parameter, and I question that. YOU said that the registrar must start comparing Vias with Paths, and I propose a way to avoid that. Regards, Christer On Aug 9, 2006, at 9:46, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > A couple of questions: > >> The issues on slide 9 (how does a registrar verify that an edge proxy > supports outbound) and slide 10 (what does >"Supported: outbound"=20 > mean) deal with detecting that all the required hops support outbound. > Slide >> 9 specifically uncovered a problem with outbound proxies that add a > Path URI but don't include a flow token. >> >> The proposed solution is as follows. If a proxy inserts a Path=20 >> header > with a flow token consistent with the rules d >> escribed in outbound, it MUST add the ;ob parameter to the proxy URI > that has the flow token. >> >> The registrar verifies that any Path header URIs contain the ;ob > parameter. If there are any Path URIs without the ob >> parameter, the registrar does not return Supported: outbound. > > [CHH] Why would every Path header need to contain the ;ob parameter?=20 > The > REGISTER request may traverse, in addition to the outbound proxy,=20 > multiple proxies which insert a Path header. Do all these proxies=20 > really need to support outbound? > >> Furthermore, the registrar needs to check that the first hop after=20 >> the > UAC is represented in the Path list (unless the >> registrar recognizes that the first hop after the UAC is in the same > domain and doesn't need to include Path URIs with a >> flow token). Note that this implies that whatever the proxy puts in > the Via (IP address or FQDN), it must put the same >> hostname in the Path header (but there is no need for a complete URI > comparison). If the first hop is not correctly >> represented, the registrar ignores the reg-id parameter and does not > return Supported: outbound. > > [CHH] Isn't it much easier to mandate the outbound proxy to always=20 > insert a Path header? > > OR, another possibility is that the outbound proxy, if it detects that > the UAC supports outbound, insert some option-tag of itself in the=20 > Supported header, to indicate to the registrar that it supports=20 > outbound. Then the registrar does not need start looking at the Path=20 > headers. > > Regards, > > Christer > > > > > > > > > The implication of this is that an outbound-proxy that supports=20 > outbound needs to support Path and flow tokens for registrations to=20 > all foreign domains. Inside the same domain, the first-hop proxy and=20 > the registrar can still use Path to communicate with each other, but=20 > they can use some other private mechanism to disaggregate this=20 > functionality. > > thanks, > -rohan > > > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 02:24:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3wA-0001g0-1n; Thu, 10 Aug 2006 02:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3w9-0001fv-9Z for sip@ietf.org; Thu, 10 Aug 2006 02:22:33 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB3w7-0004Ow-Kj for sip@ietf.org; Thu, 10 Aug 2006 02:22:33 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D67D46E0001; Thu, 10 Aug 2006 08:22:30 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 08:22:30 +0200 Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 08:22:30 +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 Subject: RE: [Sip] Question regarding instance ID in GRUU and outbound Date: Thu, 10 Aug 2006 08:22:29 +0200 Message-ID: <33D71F0FC0684C4C8A3BB76989EDED9C024BC4D3@eesmdmw020.eemea.ericsson.se> In-Reply-To: <2CB5B0AC-F06D-4E9B-83B7-299146798CB1@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question regarding instance ID in GRUU and outbound Thread-Index: Aca8RVrf2fZZWkknTwiCKvbDj9VwtA== From: "Jesus Javier Arauz \(MI/EEM\)" To: "Dean Willis" , "Aki Niemi" X-OriginalArrivalTime: 10 Aug 2006 06:22:30.0430 (UTC) FILETIME=[5BB9B3E0:01C6BC45] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Probably Dr. Rosenberg is the right person to answer this, but to my = understanding the instance ID has two complementary usages: 1) allow the construction of GRUUs in a stateless manner in registrars; = e.g. the registrar does not need to store the GRUUs it has allocated = since it can generate them algorithmically from the AoR and the instance = ID. This issue is of utterly importance for telecom-grade platforms = where storage space is scarce; if an IMS registrar has to persistently = and eternally store all the GRUUs it generates it would take several Gbs = of expensive RAM memory to do it. 2) provide a simple way to statelessly guarantee uniqueness of GRUUs, = e.g. when a multi-host registrar is in the game. Web servers guarantee = uniqueness of cookies by using very long values as cookies. Exchanging = those long values over limited bandwidth links like e.g. those of a UMTS = radio access network decreases the net bandwidth available for media. Obviously a malicious UA might attempt to tweak this mechanism for its = own obscure purposes. However the chances that it suceeds are low; even = though that UA tried to force collisions by using tweaked instance IDs, = in the worst case the instance ID is only one part of the GRUU, the AoR = being the other. Since the AoR is authenticated and cannot be tweaked, = the GRUU will still be unique no matter what the client puts in the = instance ID. Re-using the instance ID mechanism in sip-outbound enables the usage of = the same Contact values for both GRUU and outbound, which IMHO makes = sense. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: mi=E9rcoles, 09 de agosto de 2006 16:36 To: Aki Niemi Cc: sip Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound On Aug 9, 2006, at 3:49 AM, Aki Niemi wrote: > ti, 2006-08-08 kello 18:29 -0500, ext Dean Willis kirjoitti: >> >> The only way we could come up with to do this (that didn't require=20 >> eternal state in the registrar) was to make the assigned GRUU=20 >> dependent on a transformation of "something unique to the client". > > Actually, this is completely orthogonal to the issue of who generates=20 > this "something". > > Similarly, I can make a website that never expires cookies. =20 > Persistence > there doesn't require browsers issuing any kind of unique IDs;=20 > browsers simply need to store the cookies they receive and offer them=20 > to sites as necessary. > Assume the browser loses the cookie and the server loses the = authentication record. How does the web site know to issue the exact same cookie the next time = the browser connects? > > But sip-outbound doesn't even have this immortality model. > Ah, I thought we were talking GRUU. > The pattern in SIP outbound is that of web cookies. I think it's not=20 > good design to ignore that pattern and go with yet another approach=20 > that kind of does the same and might work, too. > > I see at least three problems with sip-outbound's use of the UUID URN: > > 1) It's generally a bad idea (and a security risk) to rely on the UA=20 > generating data to be used in registrar-internal state lookups. > Even if > the UUID seems all dandy and easy to use in database lookups, I'd=20 > still prefer to decide exactly with which data I populate my own=20 > database that holds my own internal state. > > 2) Generating a UUID is yet another obscure specification to read,=20 > interpret correctly and implement. I fear implementations won't get=20 > this right, and the registrar will simply have to make due with crappy = > instance IDs UAs are giving it. It has no other choice, even when=20 > those IDs are generated my malicious UAs that intentionally look for=20 > collisions. But if we're already doing all this for GRUU, why not just use the same = thing? The "malicious UA" thing is interesting. It might apply to GRUU as well. = I haven't thought about this. Anybody out there think it though yet? -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 02:48:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB4Jv-00033I-1M; Thu, 10 Aug 2006 02:47:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB4Jt-00033D-TS for sip@ietf.org; Thu, 10 Aug 2006 02:47:05 -0400 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB4Js-0007dS-0A for sip@ietf.org; Thu, 10 Aug 2006 02:47:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Undefined UAS behaviour in RFC3261 12.2.2 Date: Thu, 10 Aug 2006 07:47:01 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0012A35C0@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Undefined UAS behaviour in RFC3261 12.2.2 thread-index: Aca8M86pFzg3ie1+TpqRDIZ5NnnPswAEUXfQ From: "Attila Sipos" To: "James M. Polk" , "Molodyko, Rostislav" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> CSEq numbers are independent between Methods. In other=20 >> words, the PRACK=20 >> and UPDATE can be using the same CSeq numbers, You need a new CSeq for each new request sent by a UA irrespective of the method. In RFC3261 it says: CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number. Also from "12.2.1.1 Generating the Request"... Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowledged or cancelled). So this means that you have to use a new CSeq for each new request whatever method that request has. So you can't send a PRACK with a CSeq of 2 (for example) and then send (from the same UA) an UPDATE with a CSeq of 2. The UPDATE should have a CSeq of 3. And with respect to what the UAS should do, I refer you to Dale Worley's earlier mail: >>If the UAS notices the problem, it can reject the request with 500. >>But it is not required to detect the problem, it might just re-send >>the response to the first request. Regards, Attila Attila Sipos http:/www.vegastream.com >> -----Original Message----- >> From: James M. Polk [mailto:jmpolk@cisco.com] >> Sent: 10 August 2006 05:17 >> To: Molodyko, Rostislav; sip@ietf.org >> Subject: Re: [Sip] Undefined UAS behaviour in RFC3261 12.2.2 >>=20 >>=20 >> Ros >>=20 >> CSEq numbers are independent between Methods. In other=20 >> words, the PRACK=20 >> and UPDATE can be using the same CSeq numbers, which have to always=20 >> increase by 1 within a new transaction of that Method=20 >> regardless who the=20 >> UAS is (retransmissions have the same CSeq number as the=20 >> original request). >>=20 >> Therefore you would not get an error unless a new request=20 >> had the same Cseq=20 >> number using the same Method *or* a new request or=20 >> retransmission used a=20 >> lower number than any previous transaction used within that=20 >> same Method. >>=20 >> At 06:01 PM 8/9/2006 -0400, Molodyko, Rostislav wrote: >> >Content-class: urn:content-classes:message >> >Content-Type: multipart/alternative; >> > boundary=3D"----_=3D_NextPart_001_01C6BBFF.5CE91767" >> > >> >Hi All, >> > >> > The section 12.2.2 UAS Behavior states that UAS should : >> > >> >- reject the requests If the remote sequence number=20 >> was not empty,=20 >> >but the sequence number of the request is lower than the=20 >> remote sequence=20 >> >number >> > >> >- consider the request in-order if the sequence number of the=20 >> >request is greater than the remote sequence number >> >Not clear what UAS behaviour should be if the sequence=20 >> number is equal to=20 >> >the remote sequence number, but the incoming request is a=20 >> new request (not=20 >> >a retransmission). >> > >> > In the example below UAC sends UPDATE with the=20 >> same Cseq like=20 >> > PRACK. I guess UAS should reject that UPDATE with 500 or=20 >> 4xx, while it is=20 >> > not stated in RFC. >> > >> >At UAC side: >> > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TRANSMITTED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> >INVITE sip:6667171111@10.13.15.107:4000 SIP/2.0 >> > >> >Call-ID: 4317683@10.7.6.40 >> > >> >CSeq: 10 INVITE >> > >> >... >> > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RECEIVED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> >SIP/2.0 180 Ringing >> > >> >Call-ID: 4317683@10.7.6.40 >> > >> >CSeq: 10 INVITE >> > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TRANSMITTED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> >PRACK sip:6667171111@10.13.15.107:4000 SIP/2.0 >> > >> >Call-ID: 4317683@10.7.6.40 >> > >> >CSeq: 11 PRACK >> > >> >... >> > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RECEIVED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> >SIP/2.0 200 OK >> > >> >Call-ID: 4317683@10.7.6.40 >> > >> >CSeq: 11 PRACK >> > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TRANSMITTED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> >UPDATE sip:6667171111@10.13.15.107:4000 SIP/2.0 >> > >> >Call-ID: 4317683@10.7.6.40 >> > >> >CSeq: 11 UPDATE >> > >> >... >> > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RECEIVED: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> >SIP/2.0 200 OK // ??? >> > >> >Call-ID: 4317683@10.7.6.40 >> > >> >CSeq: 11 UPDATE >> > >> > Is this case covered by any new RFC or Draft? >> > >> >Regards, >> > >> >Ros Molodyko >> > >> >SIP Development >> > >> >Sonus Networks >> > >> >250 Apollo Drive >> > >> >Chelmsford, MA 01824 >> > >> >Direct phone: 978-614-8620 >> > >> > >> > >> >_______________________________________________ >> >Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 02:56:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB4Qs-00078D-DK; Thu, 10 Aug 2006 02:54:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB4Qr-000788-JJ for sip@ietf.org; Thu, 10 Aug 2006 02:54:17 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB4Qp-00080q-PV for sip@ietf.org; Thu, 10 Aug 2006 02:54:17 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 06C7A4F005B; Thu, 10 Aug 2006 08:54:13 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 08:54:12 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 08:54:12 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Thu, 10 Aug 2006 08:54:11 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1307@esealmw113.eemea.ericsson.se> In-Reply-To: <01a501c6bc0a$99722f90$b7c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca8APouEYFzx3rSSBCm7wodrqt3PAABQ/yAABCwU1A= From: "Christer Holmberg \(JO/LMF\)" To: "Hadriel Kaplan" , "Cullen Jennings" X-OriginalArrivalTime: 10 Aug 2006 06:54:12.0101 (UTC) FILETIME=[C935AB50:01C6BC49] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I think Bob's proposal probably addresses your concerns and ends up=20 >being a better proposal than the one I made. > >I think Bob's proposal could get us all off this merry go round - have=20 >a look and see if you could "live with it" even if it was not your=20 >first choice. > >I would if I knew which one it was. :) > >Is it: >(1) If auto-config or auto-discovery doesn't indicate the proxy supports stun, then the UA MUST use Options, with the=20 >proxy's address as the request-uri, to verify the proxy supports STUN by checking that the proxy inserted a sip-stun=20 >option tag. (where would it stick this tag, BTW?) That's your proposal isn't it? > >Or (2) If auto-config or auto-discovery doesn't indicate the proxy supports stun, then the UA MUST verify the proxy=20 >supports stun by inserting a proxy-require sip-stun option tag, which the proxy will remove and continue to process if it=20 >supports stun, or respond negatively with a 420 Bad Extension if it does not. > >I am assuming here auto-config means any way of being configured EXCEPT through a user interface? And auto-discovery is=20 >Erkki's draft, or something similar? > >I _really_ prefer (2) because it's simpler, and I find simpler gets implemented. And tying the success/fail of a=20 >registration process to Options seems bad to me, though I can't put my finger on why. =20 >But yeah I can live with it. I don't think the UAC shall be mandated to send OPTIONS. Yes, IF the UAC wants to find out whether the outbound proxy supports STUN keep-alive before sending the REGISTER it can send OPTIONS (or whatever mechanism we'll end up with).=20 But, as discussed in the "Re: [Sip] Outbound Issues: slides 3 and 4 - using Path/Supported to indicate STUN keepalive support" thread, the UAC may also find out about the support duing the registration process itself. ALSO, think the option tag value should be something like "sip-stun-keepalive", because in future we MAY need option tags for other STUN usages in SIP. Please note that we are only talking about a single STUN usage here, which does NOT require the parties to have FULL STUN support. Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 03:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB4fy-0002h5-MJ; Thu, 10 Aug 2006 03:09:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB4fx-0002h0-4I for sip@ietf.org; Thu, 10 Aug 2006 03:09:53 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB4fv-0001PW-KT for sip@ietf.org; Thu, 10 Aug 2006 03:09:53 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J3R00K01T8XEE@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Aug 2006 08:10:09 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J3R00J3DT8UC8@siemenscomms.co.uk>; Thu, 10 Aug 2006 08:10:06 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Aug 2006 08:09:46 +0100 Content-return: allowed Date: Thu, 10 Aug 2006 08:09:45 +0100 From: "Elwell, John" Subject: RE: [Sip] Question regarding instance ID in GRUU and outbound To: Jonathan Rosenberg , Aki Niemi Message-id: <50B1CBA96870A34799A506B2313F26670998BF40@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Furthermore, a UA that is in the habit of registering in more than one domain (in support of mobility, hot-desking, or whatever) would need to remember multiple cookies - gets complicated. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 09 August 2006 22:35 > To: Aki Niemi > Cc: sip > Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound > > Aki, > > Can you point to anything wrong with the current approach? The only > evidence of a problem that I saw in this discussion was that > it would be > harder to implement UUID URN than a cookie mechanism. YMMV on > that one. > > Consequently, if it aint broke - don't fix it. I am loathe to > reopen the > whole gruu/outbound design technique without a concrete problem being > identified. > > I also think its easier for a server to remember an instance > ID to GRUU > binding for a long time, than it is for a client to remember > its cookie > for a long time AND for the server to remember the cookie to GRUU > mapping for a long time. GRUU persistence would depend on a client > remembering its cookie basically forever. GRUU currently > doesn't require > persistent storage of any soft state in the client. > > -Jonathan R. > > Aki Niemi wrote: > > > Howdy, > > > > I read GRUU and outbound, and an old nagging concern of > mine resurfaced: > > what the heck do we need the instance ID for? > > > > Seems outbound uses it to guarantee uniqueness of flows in > a registrar, > > but to me it sounds weird that the task of acquiring unique > IDs within > > the registrar's internal state is left to the UA -- after > all, browsers > > don't generally generate cookies themselves but store whatever the > > website gives them. > > > > To me, a much better approach would be to have the > registrar generate > > and allocate a unique ID (perhaps the 'opaque' used in > GRUU?) for the > > first REGISTER, and whenever a client registers with that > ID again, it > > is deemed the same UA. A REGISTER without an ID would be another UA > > instance. > > > > Even DHCP clients' leases seem to survive reboots without > some weird URN > > generation, so I don't think that it's unreasonable to > require UAs to > > store their outbound IDs either. I mean, they already have > to store the > > reg-id, no? (Not to mention web cookies...) > > > > And worst case is you need to garbage-collect some stale > flows, in case > > a UA happens to forget its ID, but that you need to be doing in any > > case. > > > > We chose a similar approach over instance ID in PUBLISH, which uses > > etags generated by the server to identify uniqueness of publisher > > instances. With PUBLISH, UAs are also instructed to remember their > > etags, even across reboots. > > > > Cheers, > > Aki > > > > > > _______________________________________________ > > Sip mailing list https://www1.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 > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 03:28:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB4w9-0006QN-1H; Thu, 10 Aug 2006 03:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB4w7-0006QI-GT for sip@ietf.org; Thu, 10 Aug 2006 03:26:35 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB4w5-0002IR-Kg for sip@ietf.org; Thu, 10 Aug 2006 03:26:35 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AB8C84F001C; Thu, 10 Aug 2006 09:26:28 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 09:26:28 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 09:26:28 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 - the problem ... Date: Thu, 10 Aug 2006 09:26:26 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1309@esealmw113.eemea.ericsson.se> In-Reply-To: <44DA5A66.70403@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 - the problem ... Thread-Index: Aca7/uJLr7PbqKL2QYy2z9VDT5yr3AAS0eqw From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" , "Cullen Jennings" X-OriginalArrivalTime: 10 Aug 2006 07:26:28.0002 (UTC) FILETIME=[4B18B820:01C6BC4E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>If you want to know before you send the REGISTER request, you can do=20 >>>that. But, again, I think the outbound proxy should be able to =20 >>>indicate the support, e.g. by inserting keepalive=3Dstun in the Path header. >>Sure, I'm fine with the UA discovering URI via path or other =20 >>mechanisms that have the flag then starting using it on connection to theses URI. >>But I think this is out of scope of this draft. > >I agree its out of scope. But its relevant here as it comes back to problem statement. I am not sure I agree its out of scope. The draft defines the STUN keepalive usage for SIP, and as part of that we define option tags, and how SIP entities may use them. Please note that my proposal is not really a outbound proxy discovery mechanism, because when the REGISTER is sent some kind of "discovery" has already been done. My proposal simply allows a proxy to indicate that it supports STUN keepalive. Anyway, if you DO agree that it's relevant we don't need to argue whether it's in the scope or not :) >The root issue here is that someone constructs a URI with keepalive=3Dstun when it shouldn't have. There are two reasons=20 >we've been discussing why this might happen: > >1. a user types in their outbound proxy and adds keepalive=3Dstun when they shouldn't have 2. outbound proxy is discovered=20 >via DHCP, and since DHCP provides a hostname and not a URI, a UA constructs a URI, and since it supports the stun=20 >keepalive adds the parameter > >Case #2 is a legitimate cause for concern. However if we had a mechanism for autodiscovery of outbound proxies, where a=20 >URI was provided by that proxy itself, then this use case goes away, and the need for some of these verification=20 >mechanisms goes away too. One issue I have with the URI parameter is that we use the URI as some kind of "configuration file". What about other (current of future) proxy capabilities? Should we be able to indicate those in the URI too? Maybe we for example want to indicate that the outbound proxy supports session-timer (maybe a bad example, but anyway)...=20 Sip:myproxy@operator.com;keepalive=3Dstun;session-timer=3Dyes;capability-= x=3Dy yy;capability-y=3Dzzz... Also, EVEN if we DO use the URI to provide the information, I see no reason why all this information then should be sent to the network (I think someone else mentioned that also) in the SIP request(s) sent by the UAC. Anyway, that is out of the scope, so we don't need to discuss it as part of this thread :) >So, I had proposed at the mike during ietf a mechanism for discovery using Service-Route (Path is the wrong direction), Doesn't this mean that the outbound proxy would have to insert a Service-Route header with the STUN keepalive indication? Or, would the proxy insert the indication in the Path of the request, and the registrar would then copy the indication into the Service-Route of the response? Is this related to your route contstruct ideas? >which would make sure that, even if a client discovers the proxy initially via DHCP, it quickly learns a URI from that=20 >proxy which would inform it about whether stun is supported. Draft coming soon on this... > >If we had such a mechanism, then I dont think we need any of this mess. >In particular, though I dont really see a lot of harm in Rohans Proxy-Require proposal, I think its unnecessary=20 >complexity if you have a proper discovery mechanim. Since we need a proper discovery mechanism regardless lets solve that=20 >problem and ditch the extra mechanism. If someone wants to use Proxy-Require he/she could of course be allowed to do that, IF he/she wants to be sure the proxy supports STUN keepalive before sending a REGISTER.=20 BUT, again, I don't think one should be mandated to use Proxy-Require. The UAC should be able to find out during the registration procedure, and the UAC may then choose to continue the registration even if the outbound proxy does not support STUN keepalive... Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 04:30:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB5tR-0008Ad-5j; Thu, 10 Aug 2006 04:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB5tP-0008AV-6D for sip@ietf.org; Thu, 10 Aug 2006 04:27:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB4oy-0001vV-J5 for sip@ietf.org; Thu, 10 Aug 2006 03:19:12 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GB4lR-0003Tl-9y for sip@ietf.org; Thu, 10 Aug 2006 03:15:34 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k7A7FM9r023461 for ; Thu, 10 Aug 2006 00:15:24 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k7A7FLjA027270 for ; Thu, 10 Aug 2006 02:15:22 -0500 (CDT) 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 Subject: RE: [Sip] What makes PoC Client IMS compliant Date: Thu, 10 Aug 2006 15:15:16 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B03619C88@ZMY16EXM66.ds.mot.com> In-Reply-To: <20060810100410.BXY08641@mail.tataelxsi.co.in> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What makes PoC Client IMS compliant Thread-Index: Aca8NObPQQbgNnvSQn2uscHwdE99twAFwLNA From: "Avasarala Ranjit-A20990" To: "Rathod Subhashchandra" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.6 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rathod Your PoC client should be OMA PoC compliant. The Open Mobile Alliance/PoC is an industry approach providing baseline of protocols, interfaces and features for PTT based services. The OMA/PoC compliant PoC client can be easily integrated with IMS systems. Regards=20 Ranjit=20 -----Original Message----- From: Rathod Subhashchandra [mailto:rathod@tataelxsi.co.in]=20 Sent: Thursday, August 10, 2006 10:04 AM To: sip@ietf.org Subject: [Sip] What makes PoC Client IMS compliant Hi All, I have developed a PoC client. I am asked that is it a IMS compliant? I don't know what IMS compliant means here. Can anyone help me understanding this question? Is it a valid question? Thanks in advance for a quick reply. Thanks ! Rathod. _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 04:38:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB61g-0006Kl-WD; Thu, 10 Aug 2006 04:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB61f-0006JB-Ee for sip@ietf.org; Thu, 10 Aug 2006 04:36:23 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB61d-0003DC-0g for sip@ietf.org; Thu, 10 Aug 2006 04:36:23 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id E34381EBDF3 for ; Thu, 10 Aug 2006 10:36:19 +0200 (CEST) Received: from [192.168.1.42] ([192.168.1.42]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:35:15 +0200 In-Reply-To: <00a801c6bbde$ddffa3d0$b7c8000a@acmepacket.com> References: <00a801c6bbde$ddffa3d0$b7c8000a@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <36458eda3afd3c62b32d47bc48e24bbe@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Thu, 10 Aug 2006 10:36:52 +0200 To: "Hadriel Kaplan" X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 10 Aug 2006 08:35:15.0114 (UTC) FILETIME=[E70C08A0:01C6BC57] X-Spam-Score: 1.8 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org, 'Rohan Mahy' , 'Fredrik Thulin' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 8:08 PM, Hadriel Kaplan wrote: > >> . > > Au contraire. I would argue fairly vehemently that a server explicitly > indicating it supports something is far more reliable than a UA > believing > the server supports something based on a local config setting. The > former > is an explicit indication by the guy who's responsible for doing that > mechanism, whether he can do it or not; the latter is a guess by the > client > as to the other side's capabilities. Certainly the proxy can be > wrong, but > that probability is miniscule to the odds that one UA out of a large > population will be wrong. Ok, so lets standardise a mechanism for servers to explicitly indicate that it supports the following, even if configured in the client: - STUN - loose-routing - comp=sigcomp - ... Hisham _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 04:40:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB63r-00008s-NS; Thu, 10 Aug 2006 04:38:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB63p-00008n-SK for sip@ietf.org; Thu, 10 Aug 2006 04:38:37 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB63p-0003J4-9l for sip@ietf.org; Thu, 10 Aug 2006 04:38:37 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id AB1001EBF44 for ; Thu, 10 Aug 2006 10:38:36 +0200 (CEST) Received: from [192.168.1.42] ([192.168.1.42]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:37:31 +0200 In-Reply-To: <44DA58A8.2020307@cisco.com> References: <0590a1057c40fa96aee3d22cb551fb87@telio.no> <44DA58A8.2020307@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: using mapped addresses from stun in sip-outbound, was: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Thu, 10 Aug 2006 10:39:09 +0200 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 10 Aug 2006 08:37:31.0921 (UTC) FILETIME=[38972010:01C6BC58] X-Spam-Score: 1.8 (+) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 11:50 PM, Jonathan Rosenberg wrote: > changing topics here. > > Hisham - why would you want to do this? The whole idea of sip-outbound > is to make the IP in the Contact irrelevant. It will be ignored > anyway. Perhaps you are worried about an outbound proxy that supports > stun but a registrar that doesn't support sip-outbound? We are looking into supporting stun keepalive first in our network. sip-outbound is not being considered to be deployed at the same time. If you remember, I did ask for these 2 things to be split into separate drafts. Hisham > > There are some pretty sizeable security risks in doing this. In > particular, as long as the client doesn't actually use the mapped > address that comes back - but rather uses it as a hint to go do > something else - you can get away without authenticating the stun > transactions. If you actually use the mapped address from the stun > response in the Contact, an attacker can send a spoofed stun response > can incoming calls get routed to him instead. This is partly (and only > partly) fixable if you authenticate stun responses. However, once you > require stun authentication then the whole performance benefit of stun > goes away. > > Thanks, > Jonathan R. > > > > Hisham Khartabil wrote: > >> I don't like this proposal. I'm still with the camp that says: if >> configured, then it must be true. >> My main objection is that in this proposal, you are required to send >> SIP messages before STUN messages. That's a mandate that I'm not >> comfortable with since I might want to send STUN first to discover my >> public IP/port to populate the contact header before I send the first >> REGISTER. >> Hisham >> On Aug 8, 2006, at 4:38 PM, Rohan Mahy wrote: >>> >>> We had a very long discussion in Montreal about discovery and >>> validation of a SIP outbound proxy server's ability to receive STUN >>> requests. While the vast majority of the room was comfortable that >>> "keepalive=stun" in a URI was a sufficient indicator that an >>> outbound proxy supports SIP and STUN over the same port, a small but >>> extremely vocal minority had significant problems with this >>> assumption. After a discussion with Dean, I am willing to try a >>> validation proposal which adds no extra round trips if the SIP UA >>> was indeed correctly configured. >>> >>> The specific proposal works like this. A UAC which has an outbound >>> URI indicating with ;keepalive=stun that the next hop can support >>> STUN messages on the SIP port, needs to verify the first hop >>> supports STUN before sending any STUN messages. The UAC sends its >>> first SIP message to the next hop with a Proxy-Require: sip-stun. >>> If the URI was correct (STUN was supported), and the first-hop is an >>> intermediary, the first-hop removes the Proxy-Require and forwards >>> the SIP request (probably a REGISTER request) along adding no >>> additional delay. A positive response to a REGISTER or OPTIONS with >>> Supported: outbound and no error counts as positive confirmation >>> that either the registrar supports STUN or expects to never receive >>> a request without getting it from an outbound proxy which did not >>> complain about the Proxy-Require [1]. If the UAC was misconfigured >>> (the first-hop intermediary does not support STUN keepalives), >>> either the first hop will reject the SIP request (if it is an >>> intermediary), or the registrar will not include an indicator that >>> it supports outbound (if the first hop was the registrar). >>> >>> Note that this proposal is not a full *discovery* mechanism, just a >>> verification mechanism. For example, if the registrar doesn't >>> support outbound, but the first-hop does, there is no way described >>> here to discover that the first-hop can accept STUN keepalives. Do >>> not confuse support of STUN with support of outbound. Supported: >>> outbound implies that the registrar supports STUN or is configured >>> to use an outbound proxy that does. The sip-stun option tag only >>> means that you can send and receive STUN requests on your SIP port. >>> While outbound requires STUN, STUN does not require outbound. >>> >>> [1] Also Note that there is a caveat that you can still shoot >>> yourself in the foot if you allow messages to come straight to your >>> registrar that does not support STUN. I think we agreed that we are >>> not going to enumerate all the ways you can subtly break things in >>> SIP though. >>> >>> thanks, >>> -rohan >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.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://www1.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 > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 05:58:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB7H1-00068E-MG; Thu, 10 Aug 2006 05:56:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB7H0-000689-HI for sip@ietf.org; Thu, 10 Aug 2006 05:56:18 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB7Gx-0004mH-FJ for sip@ietf.org; Thu, 10 Aug 2006 05:56:18 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D09204F0066; Thu, 10 Aug 2006 11:56:14 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 11:56:14 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 11:56:14 +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 Subject: RE: using mapped addresses from stun in sip-outbound, was: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Thu, 10 Aug 2006 11:56:12 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1310@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: using mapped addresses from stun in sip-outbound, was: Re: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca8WGUZuW7SIPvCS6ahgBl83s9U/AACd9hA From: "Christer Holmberg \(JO/LMF\)" To: "Hisham Khartabil" , "Jonathan Rosenberg" X-OriginalArrivalTime: 10 Aug 2006 09:56:14.0148 (UTC) FILETIME=[3741C840:01C6BC63] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>changing topics here. >> >>Hisham - why would you want to do this? The whole idea of sip-outbound >>is to make the IP in the Contact irrelevant. It will be ignored=20 >>anyway. Perhaps you are worried about an outbound proxy that supports=20 >>stun but a registrar that doesn't support sip-outbound? >> >We are looking into supporting stun keepalive first in our network.=20 >sip-outbound is not being considered to be deployed at the same time.=20 >If you remember, I did ask for these 2 things to be split into separate drafts. I asked for it also. And, I think the decission was that the 2 things WILL be split, even if they will still be described in the same physical draft. But, still, the STUN keepalive usage has nothing to do with STUN IP address discovery usage. Those are two completely separate STUN usages. Of course, you can use them together, but you can also use STUN keepalive without STUN IP discovery - even if you do NOT use outbound. Regards, Christer > There are some pretty sizeable security risks in doing this. In=20 > particular, as long as the client doesn't actually use the mapped=20 > address that comes back - but rather uses it as a hint to go do=20 > something else - you can get away without authenticating the stun=20 > transactions. If you actually use the mapped address from the stun=20 > response in the Contact, an attacker can send a spoofed stun response=20 > can incoming calls get routed to him instead. This is partly (and only > partly) fixable if you authenticate stun responses. However, once you=20 > require stun authentication then the whole performance benefit of stun > goes away. > > Thanks, > Jonathan R. > > > > Hisham Khartabil wrote: > >> I don't like this proposal. I'm still with the camp that says: if=20 >> configured, then it must be true. >> My main objection is that in this proposal, you are required to send=20 >> SIP messages before STUN messages. That's a mandate that I'm not=20 >> comfortable with since I might want to send STUN first to discover my >> public IP/port to populate the contact header before I send the first >> REGISTER. >> Hisham >> On Aug 8, 2006, at 4:38 PM, Rohan Mahy wrote: >>> >>> We had a very long discussion in Montreal about discovery and=20 >>> validation of a SIP outbound proxy server's ability to receive STUN=20 >>> requests. While the vast majority of the room was comfortable that=20 >>> "keepalive=3Dstun" in a URI was a sufficient indicator that an=20 >>> outbound proxy supports SIP and STUN over the same port, a small but >>> extremely vocal minority had significant problems with this=20 >>> assumption. After a discussion with Dean, I am willing to try a=20 >>> validation proposal which adds no extra round trips if the SIP UA=20 >>> was indeed correctly configured. >>> >>> The specific proposal works like this. A UAC which has an outbound=20 >>> URI indicating with ;keepalive=3Dstun that the next hop can support=20 >>> STUN messages on the SIP port, needs to verify the first hop=20 >>> supports STUN before sending any STUN messages. The UAC sends its=20 >>> first SIP message to the next hop with a Proxy-Require: sip-stun. >>> If the URI was correct (STUN was supported), and the first-hop is an >>> intermediary, the first-hop removes the Proxy-Require and forwards=20 >>> the SIP request (probably a REGISTER request) along adding no=20 >>> additional delay. A positive response to a REGISTER or OPTIONS with >>> Supported: outbound and no error counts as positive confirmation=20 >>> that either the registrar supports STUN or expects to never receive=20 >>> a request without getting it from an outbound proxy which did not=20 >>> complain about the Proxy-Require [1]. If the UAC was misconfigured=20 >>> (the first-hop intermediary does not support STUN keepalives),=20 >>> either the first hop will reject the SIP request (if it is an=20 >>> intermediary), or the registrar will not include an indicator that=20 >>> it supports outbound (if the first hop was the registrar). >>> >>> Note that this proposal is not a full *discovery* mechanism, just a=20 >>> verification mechanism. For example, if the registrar doesn't=20 >>> support outbound, but the first-hop does, there is no way described=20 >>> here to discover that the first-hop can accept STUN keepalives. Do=20 >>> not confuse support of STUN with support of outbound. Supported: >>> outbound implies that the registrar supports STUN or is configured=20 >>> to use an outbound proxy that does. The sip-stun option tag only=20 >>> means that you can send and receive STUN requests on your SIP port. >>> While outbound requires STUN, STUN does not require outbound. >>> >>> [1] Also Note that there is a caveat that you can still shoot=20 >>> yourself in the foot if you allow messages to come straight to your=20 >>> registrar that does not support STUN. I think we agreed that we are >>> not going to enumerate all the ways you can subtly break things in=20 >>> SIP though. >>> >>> thanks, >>> -rohan >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.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 >>> >> _______________________________________________ >> Sip mailing list https://www1.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 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 06:04:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB7N2-0003D1-39; Thu, 10 Aug 2006 06:02:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB7Mz-00038U-MN for sip@ietf.org; Thu, 10 Aug 2006 06:02:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB6IY-0005pp-98 for sip@ietf.org; Thu, 10 Aug 2006 04:53:50 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GB64g-00058K-AF for sip@ietf.org; Thu, 10 Aug 2006 04:39:33 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:39:23 +0200 Received: from L-AT7568 ([10.193.5.19]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:39:22 +0200 Date: Thu, 10 Aug 2006 10:40:01 +0200 From: "Xavier Marjou" To: jdrosen@cisco.com Message-ID: X-Mailer: JBMail 3.2 X-OriginalArrivalTime: 10 Aug 2006 08:39:22.0392 (UTC) FILETIME=[7A6FA980:01C6BC58] X-Spam-Score: -2.6 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sip@ietf.org Subject: [Sip] GRUU and Mid-Dialog Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Here are my comments for the draft-ietf-sip-gruu-10.txt One major comment is the following: when I read the uses-cases of section 4, I derive the requirement that there must be a way to cause "initial" requests only to be sent to a specific UA instance. However, REQ 1 of section 11 implicitly requires it for both "initial" and "subsequent" requests? Why "subsequent" requests must also be sent to a specific UA instance? If not needed, this would remove some sections on Record-Routing (8.2.2) and the processing of subsequent requests (8.2.3). Other minor comments: p11: in the properties that a GRUU must exhibit, add that the host part of the URI must be equal to the host of the registrar that owns the GRUU. p19: replace "retain" by "copy" (I first understood by "retain" that the proxy would "screen" the grid and its value) p22: add the motivation for mandating Record-Routing at the originating home proxy. p23: "if there were no additional Route header field values ... any PATH values that were registered MUST be used". Why is this needed? On an initial request, an edge Proxy reached thanks to the Path header field had the opportunity to perform a Record-Route in order to be in the Route set in subsequent requests. As the previous sentence indicates that the remaining Route header for subsequent requests must no be touched, the Path does not have to be taken into account for subsequent requests. p29: Record-Route is missing in 200 of INVITE p31: idem for 200 of SUBSCRIBE _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 06:12:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB7Ux-0001Ov-Vl; Thu, 10 Aug 2006 06:10:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB7Ux-0001M6-0z for sip@ietf.org; Thu, 10 Aug 2006 06:10:43 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB7Uw-0007mR-8l for sip@ietf.org; Thu, 10 Aug 2006 06:10:43 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 770A04F006B; Thu, 10 Aug 2006 12:10:41 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 12:10:40 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 12:10:40 +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 Subject: RE: using mapped addresses from stun in sip-outbound, was: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Thu, 10 Aug 2006 12:10:39 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1311@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1310@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: using mapped addresses from stun in sip-outbound, was: Re: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca8WGUZuW7SIPvCS6ahgBl83s9U/AACd9hAAABPiVA= From: "Christer Holmberg \(JO/LMF\)" To: "Hisham Khartabil" , "Jonathan Rosenberg" X-OriginalArrivalTime: 10 Aug 2006 10:10:40.0376 (UTC) FILETIME=[3B91AF80:01C6BC65] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Also, if you want to use STUN for IP discovery, how you get the address of the STUN server is out of the scope.=20 I don't think you can assume that the address of the STUN server and the outbound server will be the same in that case - you may not even have an outbound server (Read: SIP entity with STUN support). The address MAY of course be the same, but I don't think we can make that assumption.=20 Because, in some cases I don't think you would like to send your STUN requests to the outbound proxy, e.g. if you want to use STUN relay for your media. Also, the outbound proxy is only required to have STUN functionlity in order to support STUN keepalive (that may be enough also for STUN IP discovery in some cases, though) =20 Regards, Christer -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: 10. elokuuta 2006 12:56 To: Hisham Khartabil; Jonathan Rosenberg Cc: IETF SIP List; Rohan Mahy Subject: RE: using mapped addresses from stun in sip-outbound,was: Re: [Sip] Outbound Issues: slides 3 and 4 Hi,=20 >>changing topics here. >> >>Hisham - why would you want to do this? The whole idea of sip-outbound >>is to make the IP in the Contact irrelevant. It will be ignored=20 >>anyway. Perhaps you are worried about an outbound proxy that supports=20 >>stun but a registrar that doesn't support sip-outbound? >> >We are looking into supporting stun keepalive first in our network.=20 >sip-outbound is not being considered to be deployed at the same time.=20 >If you remember, I did ask for these 2 things to be split into separate drafts. I asked for it also. And, I think the decission was that the 2 things WILL be split, even if they will still be described in the same physical draft. But, still, the STUN keepalive usage has nothing to do with STUN IP address discovery usage. Those are two completely separate STUN usages. Of course, you can use them together, but you can also use STUN keepalive without STUN IP discovery - even if you do NOT use outbound. Regards, Christer > There are some pretty sizeable security risks in doing this. In=20 > particular, as long as the client doesn't actually use the mapped=20 > address that comes back - but rather uses it as a hint to go do=20 > something else - you can get away without authenticating the stun=20 > transactions. If you actually use the mapped address from the stun=20 > response in the Contact, an attacker can send a spoofed stun response=20 > can incoming calls get routed to him instead. This is partly (and only > partly) fixable if you authenticate stun responses. However, once you=20 > require stun authentication then the whole performance benefit of stun > goes away. > > Thanks, > Jonathan R. > > > > Hisham Khartabil wrote: > >> I don't like this proposal. I'm still with the camp that says: if=20 >> configured, then it must be true. >> My main objection is that in this proposal, you are required to send=20 >> SIP messages before STUN messages. That's a mandate that I'm not=20 >> comfortable with since I might want to send STUN first to discover my >> public IP/port to populate the contact header before I send the first >> REGISTER. >> Hisham >> On Aug 8, 2006, at 4:38 PM, Rohan Mahy wrote: >>> >>> We had a very long discussion in Montreal about discovery and=20 >>> validation of a SIP outbound proxy server's ability to receive STUN=20 >>> requests. While the vast majority of the room was comfortable that=20 >>> "keepalive=3Dstun" in a URI was a sufficient indicator that an=20 >>> outbound proxy supports SIP and STUN over the same port, a small but >>> extremely vocal minority had significant problems with this=20 >>> assumption. After a discussion with Dean, I am willing to try a=20 >>> validation proposal which adds no extra round trips if the SIP UA=20 >>> was indeed correctly configured. >>> >>> The specific proposal works like this. A UAC which has an outbound=20 >>> URI indicating with ;keepalive=3Dstun that the next hop can support=20 >>> STUN messages on the SIP port, needs to verify the first hop=20 >>> supports STUN before sending any STUN messages. The UAC sends its=20 >>> first SIP message to the next hop with a Proxy-Require: sip-stun. >>> If the URI was correct (STUN was supported), and the first-hop is an >>> intermediary, the first-hop removes the Proxy-Require and forwards=20 >>> the SIP request (probably a REGISTER request) along adding no=20 >>> additional delay. A positive response to a REGISTER or OPTIONS with >>> Supported: outbound and no error counts as positive confirmation=20 >>> that either the registrar supports STUN or expects to never receive=20 >>> a request without getting it from an outbound proxy which did not=20 >>> complain about the Proxy-Require [1]. If the UAC was misconfigured=20 >>> (the first-hop intermediary does not support STUN keepalives),=20 >>> either the first hop will reject the SIP request (if it is an=20 >>> intermediary), or the registrar will not include an indicator that=20 >>> it supports outbound (if the first hop was the registrar). >>> >>> Note that this proposal is not a full *discovery* mechanism, just a=20 >>> verification mechanism. For example, if the registrar doesn't=20 >>> support outbound, but the first-hop does, there is no way described=20 >>> here to discover that the first-hop can accept STUN keepalives. Do=20 >>> not confuse support of STUN with support of outbound. Supported: >>> outbound implies that the registrar supports STUN or is configured=20 >>> to use an outbound proxy that does. The sip-stun option tag only=20 >>> means that you can send and receive STUN requests on your SIP port. >>> While outbound requires STUN, STUN does not require outbound. >>> >>> [1] Also Note that there is a caveat that you can still shoot=20 >>> yourself in the foot if you allow messages to come straight to your=20 >>> registrar that does not support STUN. I think we agreed that we are >>> not going to enumerate all the ways you can subtly break things in=20 >>> SIP though. >>> >>> thanks, >>> -rohan >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.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 >>> >> _______________________________________________ >> Sip mailing list https://www1.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 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 09:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBA7j-0007oj-Oc; Thu, 10 Aug 2006 08:58:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBA7i-0007oe-6F for sip@ietf.org; Thu, 10 Aug 2006 08:58:54 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBA7f-0002KO-Qv for sip@ietf.org; Thu, 10 Aug 2006 08:58:54 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 10 Aug 2006 05:58:52 -0700 X-IronPort-AV: i="4.08,110,1154934000"; d="scan'208"; a="1845896072:sNHT26806160" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7ACwpHP022497; Thu, 10 Aug 2006 05:58:51 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7ACwiIt000473; Thu, 10 Aug 2006 05:58:50 -0700 (PDT) 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); Thu, 10 Aug 2006 08:58:25 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 08:58:21 -0400 Message-ID: <44DB2D6D.4070008@cisco.com> Date: Thu, 10 Aug 2006 08:58:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Jesus Javier Arauz (MI/EEM)" Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <33D71F0FC0684C4C8A3BB76989EDED9C024BC4D3@eesmdmw020.eemea.ericsson.se> In-Reply-To: <33D71F0FC0684C4C8A3BB76989EDED9C024BC4D3@eesmdmw020.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 12:58:21.0986 (UTC) FILETIME=[A8C18820:01C6BC7C] DKIM-Signature: a=rsa-sha1; q=dns; l=1567; t=1155214731; x=1156078731; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Question=20regarding=20instance=20ID=20in=20GRUU=20and=2 0outbound; X=v=3Dcisco.com=3B=20h=3DOa/VNwPzdLqO79eqZZ6+DMJpgWI=3D; b=O/TdVF+AD49BmwkB/MW1FBJB1YWb5WQySzX+wvFA+AwfuIBzF1oKEZEMqOQ7TLqWwlSr304/ ssYuBwG7JGOl/EbNGrVnh50xMAPvERqMSXfHNcqjrMOQF4I+WxFElPJU; Authentication-Results: sj-dkim-6.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip , Aki Niemi , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jesus Javier Arauz (MI/EEM) wrote: > Obviously a malicious UA might attempt to tweak this mechanism for its own obscure purposes. However the chances that it suceeds are low; even though that UA tried to force collisions by using tweaked instance IDs, in the worst case the instance ID is only one part of the GRUU, the AoR being the other. Since the AoR is authenticated and cannot be tweaked, the GRUU will still be unique no matter what the client puts in the instance ID. There is very little that a UA can do to pervert this mechanism for some value. By lying about the instance id, all it can do is: - appear to be multiple instances, rather than a single one - impersonate some other instance appearing to be multiple instances may have value in some cases, and in any case it at most hurts the user of the device doing it. It simply provides a cheaper way of *actually* having multiple devices. Because the instance id is combined with the AOR to make a gruu, impersonation of the instance id only conflicts with other devices registering to the same AOR. Generally those all represent the same "user", and so this is only hurting the user that owns the device. This is no worse that one of the user's devices malfunctioning in some other way. There may be cases when moving an instance id among devices is a useful thing to do. It only is a problem at all when the same instance id is simultaneously used in two devices. And that is likely pilot error on the part of the user. I don't see a problem here. Paul _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 09:14:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAL6-0000tL-MB; Thu, 10 Aug 2006 09:12:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAL5-0000pr-J8 for sip@ietf.org; Thu, 10 Aug 2006 09:12:43 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBAL4-0002sZ-4H for sip@ietf.org; Thu, 10 Aug 2006 09:12:43 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7ACCZSY000981; Thu, 10 Aug 2006 15:12:40 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 16:12:35 +0300 Received: from esdhcp03573.research.nokia.com ([172.21.35.73]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Aug 2006 16:12:33 +0300 Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound From: Aki Niemi To: ext Paul Kyzivat In-Reply-To: <44DA120A.1090107@cisco.com> References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44D91E3C.6020204@softarmor.com> <1155113399.16458.27.camel@macbuster.research.nokia.com> <2CB5B0AC-F06D-4E9B-83B7-299146798CB1@softarmor.com> <44DA120A.1090107@cisco.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Thu, 10 Aug 2006 16:12:34 +0300 Message-Id: <1155215554.7999.43.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 13:12:33.0755 (UTC) FILETIME=[A4732AB0:01C6BC7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ke, 2006-08-09 kello 12:49 -0400, ext Paul Kyzivat kirjoitti: > In theory they could use different techniques, though the value of that > seems dubious to me. If they both use the same id, then it has to meet > both of their needs. As things stand it does. If it were to be changed > to a cookie supplied by the registrar, then its unclear if it could as > well meet both sets of needs. Like I responded to Dean, the issue of who generates the unique identifier is completely orthogonal to the issue of having to store it "indefinitely". You can just as easily lose track of client provided instance IDs at the registrar as you do those you created yourself. But I feel a lot more comfortable giving UAs handles from my own private pool. As an aside, the immortal GRUU to me is simply an alias, and for those, the other allocation scheme (namely the admin allocated) seems much more feasible. That's also a common feature in proxies, I believe. > At the moment the predominant need is to *get done*. The existing > approach has a huge advantage on that score. This, I admit, is hard to counter with my argument, which basically is "the current scheme is kind of ugly". :) Cheers, Aki -- Aki Niemi Nokia Research Center _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 09:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAQ8-0003ov-Cy; Thu, 10 Aug 2006 09:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAQ7-0003oq-4m for sip@ietf.org; Thu, 10 Aug 2006 09:17:55 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBAQ5-00039v-EB for sip@ietf.org; Thu, 10 Aug 2006 09:17:55 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 10 Aug 2006 06:17:53 -0700 X-IronPort-AV: i="4.08,110,1154934000"; d="scan'208"; a="335425521:sNHT42177404" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7ADHpY2014386; Thu, 10 Aug 2006 06:17:52 -0700 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7ADHlte025516; Thu, 10 Aug 2006 13:17:48 GMT Received: from xmb-blr-418.apac.cisco.com ([64.104.140.147]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 18:47:48 +0530 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 Subject: RE: [Sip] updated acr code draft Date: Thu, 10 Aug 2006 18:47:47 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] updated acr code draft Thread-Index: Aca53pZ3D+P/ODtEQdG/1yIiDdVJugClRs5g From: "Rajeev Narang \(ranarang\)" To: "Jonathan Rosenberg \(jdrosen\)" , X-OriginalArrivalTime: 10 Aug 2006 13:17:48.0705 (UTC) FILETIME=[602CB910:01C6BC7F] DKIM-Signature: a=rsa-sha1; q=dns; l=10464; t=1155215872; x=1156079872; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ranarang@cisco.com; z=From:=22Rajeev=20Narang=20\(ranarang\)=22=20 |Subject:RE=3A=20[Sip]=20updated=20acr=20code=20draft; X=v=3Dcisco.com=3B=20h=3DF/nY3Q2j2zfj8q7tBnYC2Qs89CM=3D; b=HOeIzuNQnme8hism1KV7R0R7gV6hdIwoFaHKb+A4iSf7z2nmFJSTMN+e0gkn5ccOy8qwK9eM fH0qqqe7tLUJl7nH6pLr27kuZsuAdSS7MElgpF94ca4g/pkT8t8//2bG; Authentication-Results: sj-dkim-2.cisco.com; header.From=ranarang@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Cc: "Jesske, R" , "Sanjay Sinha \(sanjsinh\)" , "Mohammad Al-Taraireh \(maltarai\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I think Mohammad still hasn't got the clarification. The scenario is:- UA1----dialog1-------b2bua------dialog4----UA2 dialog2|dialog3 | UA3 Say UA1 uses anonymous for its Name/Number. Say UA2 would reject the anonymous calls. UA3 is "not" using anonymous for its Name/Number and will "not" reject = anonymous calls. =20 1) UA1 calls UA3 (dialog1 and dialog2 are established) 2) UA3 puts UA1 on hold and does early attended Xfer to UA2 (dialog3 and = dialog4 are in early connected state, UA2 is still ringing). The dialog3/dialog4 INVITE dialogs will use the Name/Number of UA3 in = the From header. So UA2 will allow it as dialog4=20 is not carrying anonymous Name/Id. 3) UA3 presses the Xfer button again to complete the early attended = Xfer. Now the identity info of UA1 will be communicated on dialog4 to UA2 in = the UPDATE message say using RPID header. The INVITE dialog4 will not = change the Display Name and Id in the From header as per the UA1's = identity, so it will remain same as original, which is UA3's identity = used during dialog3/dialog4 establishent. The question is the handling of UA1's anonymity by UA2 in the UPDATE = message and affect to the INVITE dialog4. 1. Should UPDATE be responded with 433. How to handle the INVITE dialog4 = as 200 OK is still not sent on dialog4. Based on 433 for UPDATE, b2bua can send CANCEL (With Reason Header = carrying Q.850 cause=3D21 Rejected)to UA2 and UA2 can send 487 on = dialog4.=20 2. Or UPDATE is responded with 433 and later 433 is sent on INVITE = dialog4 resulting in clearing the dialog4 on UA2 and b2bua. Probably 433 = followed by 180 on INVITE dialog will not look appropriate. The dialog1 is already an established dialog so BYE will be sent. The other scenario:- If it has been attended Xfer then dialog4 would have been already = established. So in the same anonymous config the UPDATE could be responded with 433 and BYE with Reason header carrying = SIP Status=3D433 could be sent from UA2 to b2bua on dialog4. Could we get clarification on this so that standard approach can be = used. Regards, Rajeev -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: Monday, August 07, 2006 10:26 AM To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh); Jonathan = Rosenberg (jdrosen); sip@ietf.org Subject: AW: [Sip] updated acr code draft The UAC either should include the identity in the From header instead of = anonymous or don't call again if the user still wants to be anonymous. The UAS should close the transactions. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] > Gesendet: Freitag, 4. August 2006 16:13 > An: Jesske, Roland; Sanjay Sinha (sanjsinh); Jonathan Rosenberg=20 > (jdrosen); sip@ietf.org > Betreff: RE: [Sip] updated acr code draft >=20 >=20 >=20 > The identity in the From header in not the correct party after the=20 > xfer is complete! I still don't see an answer to what should the UAC=20 > do when it gets the 433 response, or what the UAS should do after it=20 > send the 433, basically how does that response impact the INVITE=20 > dialog. >=20 > Thanks, >=20 > Mo >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: Friday, August 04, 2006 4:14 AM > To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh); Jonathan = > Rosenberg (jdrosen); sip@ietf.org > Subject: AW: [Sip] updated acr code draft >=20 > There is a difference between an unavailable identity and a anonymous=20 > identity so that the endpoint can decide. > As a wrote before the From header is a mandatory header. So there must = > an identity in. >=20 > In which scenario this early attended transfer could appear is this=20 > also a interworking case or a pure SIP case? >=20 > What is with the identity I'm registering with? >=20 >=20 > BR >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] > > Gesendet: Donnerstag, 3. August 2006 16:22 > > An: Sanjay Sinha (sanjsinh); Jesske, Roland; Jonathan Rosenberg=20 > > (jdrosen); sip@ietf.org > > Cc: Mohammad Al-Taraireh (maltarai) > > Betreff: RE: [Sip] updated acr code draft > >=20 > >=20 > >=20 > > Another case is a early attended transfer. For example the transfer=20 > > target will get an INVITE without caller id blocking and then an=20 > > UPDATE after the xfer with caller id blocking to change the > display.=20 > > If there is a policy on the endpoint to reject anonymous > calls, what > > should the do in this case? which the question below "what does 433=20 > > mean for mid call UPDATE or reINVITE?" > >=20 > > Thanks, > >=20 > > Mo > >=20 > > -----Original Message----- > > From: Sanjay Sinha (sanjsinh) > > Sent: Thursday, August 03, 2006 9:57 AM > > To: Jesske, R; Jonathan Rosenberg (jdrosen); sip@ietf.org > > Subject: RE: [Sip] updated acr code draft > >=20 > > Scenario is PSTN-SIP interworking. For some cases, display > IE is not > > available in SETUP because some TCAP query is required.=20 > When the query > > is complete, switch sends display IE in a FACILITY message. From=20 > > header is mandatory in INVITE, but calling name and number > is not. So > > Invite is sent without caller-identity which is later > updated with an > > UPDATE/INFO, when the UA gets FACILITY with display information. > >=20 > > Thanks > > Sanjay.=20 > >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: Thursday, August 03, 2006 1:52 AM > > To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen);=20 > > sip@ietf.org > > Subject: AW: [Sip] updated acr code draft > >=20 > > The ACR service itself reacts only on identities that are > put anonymus > > by the user or on behalf on the user. > > So if the restriction is based on other reasons ACR will > not terminate > > the call. > >=20 > > My question to your scenario is in which case an identity is not=20 > > available in an INVITE. The From header is an mandatory > header so the > > >From Header has have an user identity. Or not? > >=20 > > The P-Asserted-Identity is set by an trusted network entity that is=20 > > aware of the user sending that request. > >=20 > > Best Regards > >=20 > > Roland > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > > Gesendet: Mittwoch, 2. August 2006 17:32 > > > An: Jonathan Rosenberg (jdrosen); IETF SIP List > > > Betreff: RE: [Sip] updated acr code draft > > >=20 > > >=20 > > > What about the case in which caller information is not > available at > > > the time INVITE is sent to establish a call, but is > available later > > > and an UPDATE/INFO is sent by UAC to update the caller-id > > information. > > > If UAS rejects UPDATE/INFO with 433, what does it mean for > > the Invite > > > dialog. > > > Should that also be terminated as a result of ACR? > > >=20 > > > Thanks > > > Sanjay > > >=20 > > > -----Original Message----- > > > From: Jonathan Rosenberg (jdrosen) > > > Sent: Monday, July 31, 2006 4:31 PM > > > To: IETF SIP List > > > Subject: [Sip] updated acr code draft > > >=20 > > > I've submitted a minor update to the ACR code draft. Until > > it appears, > > > you can pick it up at: > > >=20 > > > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt > > >=20 > > > the changes are: > > >=20 > > > * replaced P-Asserted-ID with P-Asserted-Identity > > >=20 > > > * added to security considerations section, consideration for=20 > > > anonymizers in the network. Namely, don't retry request on > > receipt of > > > 433 unless explicitly configured to do so by user > > >=20 > > >=20 > > > Thanks, > > > Jonathan R. > > > --=20 > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Cisco Fellow Parsippany, NJ=20 > > > 07054-2711 > > > Cisco Systems > > > jdrosen@cisco.com FAX: =20 > (973) 952-5050 > > > http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > > http://www.cisco.com > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.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://www1.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 > > _______________________________________________ > > Sip mailing list https://www1.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://www1.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 > _______________________________________________ > Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 09:28:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAYt-00034v-2r; Thu, 10 Aug 2006 09:26:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAYr-00034q-Rp for sip@ietf.org; Thu, 10 Aug 2006 09:26:57 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBAYq-0003bv-CH for sip@ietf.org; Thu, 10 Aug 2006 09:26:57 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7ACQr6q008277; Thu, 10 Aug 2006 15:26:54 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 16:26:39 +0300 Received: from esdhcp03573.research.nokia.com ([172.21.35.73]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Aug 2006 16:26:39 +0300 Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound From: Aki Niemi To: ext Jonathan Rosenberg In-Reply-To: <44DA550E.9020602@cisco.com> References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44DA550E.9020602@cisco.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Thu, 10 Aug 2006 16:26:38 +0300 Message-Id: <1155216398.7999.58.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 13:26:39.0031 (UTC) FILETIME=[9C460C70:01C6BC80] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ke, 2006-08-09 kello 17:35 -0400, ext Jonathan Rosenberg kirjoitti: > Aki, > > Can you point to anything wrong with the current approach? The only > evidence of a problem that I saw in this discussion was that it would be > harder to implement UUID URN than a cookie mechanism. YMMV on that one. > > Consequently, if it aint broke - don't fix it. I am loathe to reopen the > whole gruu/outbound design technique without a concrete problem being > identified. The problem I have is letting the UA create identifiers that the registrar uses in its internal state lookup. Now there isn't anything totally broken with this approach per se, but it just seems like a bad idea. So in that sense, I agree this may be "too little, too late". > I also think its easier for a server to remember an instance ID to GRUU > binding for a long time, than it is for a client to remember its cookie > for a long time AND for the server to remember the cookie to GRUU > mapping for a long time. GRUU persistence would depend on a client > remembering its cookie basically forever. GRUU currently doesn't require > persistent storage of any soft state in the client. Except it has to persistently store the instance-ID. When the UA moves to another device, it supposedly needs to take the instance ID with it? There's really no difference here to the (implicit) requirement on a UA that the UA has to store the user credentials, per AOR, in persistent storage, forever. Unless a blackphone intends to query a digest password upon every registration after a reboot cycle? That probably wouldn't work, especially with a numeric keypad and an alphanumeric password. Or at least I would toss that phone out the window pretty quickly. ;) Cheers, Aki -- Aki Niemi Nokia Research Center _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 09:31:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAbp-00053m-0r; Thu, 10 Aug 2006 09:30:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAbn-00053h-NI for sip@ietf.org; Thu, 10 Aug 2006 09:29:59 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBAbl-0003iV-E2 for sip@ietf.org; Thu, 10 Aug 2006 09:29:59 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Aug 2006 09:29:57 -0400 X-IronPort-AV: i="4.08,110,1154923200"; d="scan'208"; a="96028912:sNHT25327120" 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.20060308/8.12.11) with ESMTP id k7ADTvnS025487; Thu, 10 Aug 2006 09:29:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7ADTvdr005403; Thu, 10 Aug 2006 09:29:57 -0400 (EDT) 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, 10 Aug 2006 09:29:56 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 09:29:56 -0400 Message-ID: <44DB34D4.8040605@cisco.com> Date: Thu, 10 Aug 2006 09:29:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Xavier Marjou Subject: Re: [Sip] GRUU and Mid-Dialog Requests References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 13:29:56.0630 (UTC) FILETIME=[120D4360:01C6BC81] DKIM-Signature: a=rsa-sha1; q=dns; l=1625; t=1155216597; x=1156080597; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20GRUU=20and=20Mid-Dialog=20Requests |To:Xavier=20Marjou=20; X=v=3Dcisco.com=3B=20h=3DBHfEp4ZxQe5icuUoxUyoBEiHrTI=3D; b=in1pBDRp5p5MSWyV483AczRG3Kq2mE1GS+jxPVqW0CiqcqyfJT+92GM07Jmd9OHVX14kY7Qc nNolINyCZ0Ks12GN/RcdZhrApaxIoJDSBQUS2kG+4STC1MZih3ygDzJR; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Xavier Marjou wrote: > Here are my comments for the draft-ietf-sip-gruu-10.txt > > One major comment is the following: when I read the uses-cases of section > 4, I derive the requirement that there must be a way to cause "initial" > requests only to be sent to a specific UA instance. However, REQ 1 of > section 11 implicitly requires it for both "initial" and "subsequent" > requests? Why "subsequent" requests must also be sent to a specific UA > instance? If not needed, this would remove some sections on Record-Routing > (8.2.2) and the processing of subsequent requests (8.2.3). subsequent (in-dialog) requests are already sent to a specific UA instance by virtue of the Contact header and the Record-Route for the dialog. The point of GRUU is to allow out-of-dialog requests to target a "specific instance" in the same way that in-dialog requests do. No more, no less. The behavior of subsequent requests when the dialog was established to a gruu target doesn't require so much specification because it is existing behavior. Its enough to guarantee that the changes introduced don't break things that were already working. > Other minor comments: > > p11: in the properties that a GRUU must exhibit, add that the host part of > the URI must be equal to the host of the registrar that owns the GRUU. I don't agree that is a requirement. It could be a different host part that maps to the same IP, or a different host part that maps to a different IP but the same server, or it could map to a different server with access to the same location server. Paul _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 09:35:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAfg-0007rZ-Rw; Thu, 10 Aug 2006 09:34:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAff-0007rU-Qm for sip@ietf.org; Thu, 10 Aug 2006 09:33:59 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBAfe-00040J-B3 for sip@ietf.org; Thu, 10 Aug 2006 09:33:59 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7ADXt6V025576; Thu, 10 Aug 2006 16:33:56 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 16:33:55 +0300 Received: from esdhcp03573.research.nokia.com ([172.21.35.73]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Aug 2006 16:33:54 +0300 Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound From: Aki Niemi To: ext Cullen Jennings In-Reply-To: <3135FE06-4196-44A4-9310-0AFEF22E449D@cisco.com> References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <3135FE06-4196-44A4-9310-0AFEF22E449D@cisco.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Thu, 10 Aug 2006 16:33:54 +0300 Message-Id: <1155216834.7999.67.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 13:33:54.0317 (UTC) FILETIME=[9FB96BD0:01C6BC81] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ke, 2006-08-09 kello 15:58 -0700, ext Cullen Jennings kirjoitti: > This email is sort of irrelevant but I'm sending it anyways :-) > > A few year back, I wrote > http://www.softarmor.com/wgdb/docs/draft-jennings-sipping-instance- > id-00.txt > > and it had some use cases for why one might need a long term stable > identifier for a device. I think theses still hold. We need something > and it needs to survive reboots of a device. You are right it does > not matter who generates the ID but the UA needs to store it. Cookies > were discussed but rejected due to worries about if there was AT&T > IPR on them. This is pretty interesting. Has anyone verified there is an actual patent or patent application on the cookie approach? > I originally proposed something "simple" to generate - I'm a big fan > of large random numbers. Others were less comfortable with large > random numbers and wanted something algorithmically guaranteed to be > unique by some sort of delegated assignment - like MAC or OIDs. Most > devices had MAC addresses or an equivalent sort of identifier. I > wrote something for MAC plus something for things without a MAC. It > was looking less simple. There were problems with the multiple phones > on one MAC that added more complexity. Pretty soon, I was reinventing > UUID. UUID covered everything we needed and encompassed a huge set of > existing arguments on the subject. If you remove any part of UUID, > there is some use case that gets broken. It may be that the use case > is bogus but none the less the argument goes on. Let me be clear, I'm not against UUID as such. In fact that would be a perfectly valid spec to follow when implementing the registrar's cookie-generation algorithm. > Some devices store only > their MAC and the configuration system uses that to know what data to > hand down to them. I have seen some systems where the config handed > to the phone is based only on the which ethernet port in the switch > the device was connected to. Some residential ethernet to the home > systems do this so that if my neighbor plugs in his phone at my > house, it becomes my phone. In theory these systems would not need to > really store anything. And that configuration handed down to them couldn't just include the cookie? > > And worst case is you need to garbage-collect some stale flows, in > > case > > a UA happens to forget its ID, but that you need to be doing in any > > case. > > > > We chose a similar approach over instance ID in PUBLISH, which uses > > etags generated by the server to identify uniqueness of publisher > > instances. With PUBLISH, UAs are also instructed to remember their > > etags, even across reboots. > > of course close to none of them do :-) Touche! ;) -- Aki Niemi Nokia Research Center _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 09:40:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAjp-0001B4-9e; Thu, 10 Aug 2006 09:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBAjn-00019m-Fv for sip@ietf.org; Thu, 10 Aug 2006 09:38:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBAjm-0004HL-7E for sip@ietf.org; Thu, 10 Aug 2006 09:38:15 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Aug 2006 06:37:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,110,1154934000"; d="scan'208"; a="35486933:sNHT26669380" 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.20060308/8.12.11) with ESMTP id k7ADbvd7030410; Thu, 10 Aug 2006 09:37:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7ADbvdp008090; Thu, 10 Aug 2006 09:37:57 -0400 (EDT) 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, 10 Aug 2006 09:37:56 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 09:37:56 -0400 Message-ID: <44DB36B4.6010103@cisco.com> Date: Thu, 10 Aug 2006 09:37:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44D91E3C.6020204@softarmor.com> <1155113399.16458.27.camel@macbuster.research.nokia.com> <2CB5B0AC-F06D-4E9B-83B7-299146798CB1@softarmor.com> <44DA120A.1090107@cisco.com> <1155215554.7999.43.camel@macbuster.research.nokia.com> In-Reply-To: <1155215554.7999.43.camel@macbuster.research.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 13:37:56.0605 (UTC) FILETIME=[3023A2D0:01C6BC82] DKIM-Signature: a=rsa-sha1; q=dns; l=2093; t=1155217077; x=1156081077; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Question=20regarding=20instance=20ID=20in=20GRUU=20and=2 0outbound |To:Aki=20Niemi=20; X=v=3Dcisco.com=3B=20h=3DOa/VNwPzdLqO79eqZZ6+DMJpgWI=3D; b=BUUJ7nVOVI1RPb0I+iOOHFojPvozpVbNz5T7nEn49cqJ4R5/pKfzsfHjgQRQ1IP6fIwNguIT JkjoJm2Bs0TaLYEdGuAX5UlVllq5FHf+c87oQ12eXvCIYQVnYUfF4DL5; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki Niemi wrote: > ke, 2006-08-09 kello 12:49 -0400, ext Paul Kyzivat kirjoitti: >> In theory they could use different techniques, though the value of that >> seems dubious to me. If they both use the same id, then it has to meet >> both of their needs. As things stand it does. If it were to be changed >> to a cookie supplied by the registrar, then its unclear if it could as >> well meet both sets of needs. > > Like I responded to Dean, the issue of who generates the unique > identifier is completely orthogonal to the issue of having to store it > "indefinitely". > > You can just as easily lose track of client provided instance IDs at the > registrar as you do those you created yourself. But I feel a lot more > comfortable giving UAs handles from my own private pool. There is a huge difference. The UA can remember is instance id or not as it sees fit. In that regard it controls its own destiny. If it forgets, then old gruus stop working. It can make its own decision if that is acceptable, bad, or intended. With the current scheme, the registrar only needs to remember the instance ids while a registration is active. If it can't manage that, then it is incompetent to be a registrar. It doesn't have to remember them longer. That is a good thing, because it is not in a position to decide how long one should remain valid. Maybe you would just prefer the current scheme, except that the registrar is the only source of instance ids. I can see no advantage in that over the current scheme. And I do see considerable disadvantage. Paul > As an aside, the immortal GRUU to me is simply an alias, and for those, > the other allocation scheme (namely the admin allocated) seems much more > feasible. That's also a common feature in proxies, I believe. > >> At the moment the predominant need is to *get done*. The existing >> approach has a huge advantage on that score. > > This, I admit, is hard to counter with my argument, which basically is > "the current scheme is kind of ugly". :) > > Cheers, > Aki _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 10:01:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBB48-00086o-WD; Thu, 10 Aug 2006 09:59:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBB47-00086j-Dj for sip@ietf.org; Thu, 10 Aug 2006 09:59:15 -0400 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBB44-0005rM-4x for sip@ietf.org; Thu, 10 Aug 2006 09:59:15 -0400 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k7ADxBx12178 for ; Thu, 10 Aug 2006 08:59:11 -0500 Date: Thu, 10 Aug 2006 08:59:11 -0500 Message-Id: <200608101359.k7ADxBx12178@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: sip@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] Article of interest X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org http://www.lightreading.com/document.asp?doc_id=100877&WT.svl=news1_6 I think there are actually two very good points in this article: 1) The potential for non-standard splinters, e.g. IMS is a good example 2) Creeping complexity FM _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 10:03:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBB6C-0001M1-1p; Thu, 10 Aug 2006 10:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBB6A-00017l-1A for sip@ietf.org; Thu, 10 Aug 2006 10:01:22 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBB68-0005y9-Ed for sip@ietf.org; Thu, 10 Aug 2006 10:01:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Aug 2006 10:01:21 -0400 X-IronPort-AV: i="4.08,110,1154923200"; d="scan'208"; a="96036059:sNHT53710524" 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.20060308/8.12.11) with ESMTP id k7AE1Ku2012421; Thu, 10 Aug 2006 10:01:20 -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.12.10/8.12.6) with ESMTP id k7AE1Edv015256; Thu, 10 Aug 2006 10:01:19 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:01:18 -0400 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 Subject: RE: [Sip] updated acr code draft Date: Thu, 10 Aug 2006 10:01:16 -0400 Message-ID: <47F3B0799A62BB48B096A4DC5BB3B11D01CEAF4E@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] updated acr code draft Thread-Index: Aca53pZ3D+P/ODtEQdG/1yIiDdVJugClRs5gAAQx53A= From: "Mohammad Al-Taraireh \(maltarai\)" To: "Rajeev Narang \(ranarang\)" , "Jonathan Rosenberg \(jdrosen\)" , X-OriginalArrivalTime: 10 Aug 2006 14:01:18.0073 (UTC) FILETIME=[737AAE90:01C6BC85] DKIM-Signature: a=rsa-sha1; q=dns; l=11323; t=1155218480; x=1156082480; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=maltarai@cisco.com; z=From:=22Mohammad=20Al-Taraireh=20\(maltarai\)=22=20 |Subject:RE=3A=20[Sip]=20updated=20acr=20code=20draft |To:=22Rajeev=20Narang=20\(ranarang\)=22=20, =0A=20=20=20 =20=20=20=20=20=22Jonathan=20Rosenberg=20\(jdrosen\)=22=20,=20; X=v=3Dcisco.com=3B=20h=3D7AnlpAKvVe8FqShot/tfaxrRQpU=3D; b=kGb15zfW1Krh1ssZ/5+xD6KHgvnPFjPBPr/fqv9wusIZ6uoI+HaBZTY7D3mfUbl5nxyGtFoq lUgfd9KlxuqPjkfeU82QrxDlPC1qiR1qGL0llAOJ+g3IWCJz40USyqcK; Authentication-Results: rtp-dkim-1.cisco.com; header.From=maltarai@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: "Jesske, R" , "Sanjay Sinha \(sanjsinh\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In the B2BUA case we probably need more than just the acr code draft to = address this issue. The B2BUA needs something in the backward direction = to let UA1 know that the "Anonymous" id is not allowed after it gets the = 433 response from UA2, to give UA1 the opportunity to reveal its id if = it wishes or to keep it as "Anonymous". Since we don't have that yet, = the B2BUA should probably just CANCEL the early dialog after it gets the = 433 response to the UPDATE. This is not the best user experience but it = will enforce the configured policy on UA2. Thanks, Mo -----Original Message----- From: Rajeev Narang (ranarang)=20 Sent: Thursday, August 10, 2006 9:18 AM To: Jonathan Rosenberg (jdrosen); sip@ietf.org Cc: Jesske, R; Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh) Subject: RE: [Sip] updated acr code draft Hi, I think Mohammad still hasn't got the clarification. The scenario is:- UA1----dialog1-------b2bua------dialog4----UA2 dialog2|dialog3 | UA3 Say UA1 uses anonymous for its Name/Number. Say UA2 would reject the anonymous calls. UA3 is "not" using anonymous for its Name/Number and will "not" reject = anonymous calls. =20 1) UA1 calls UA3 (dialog1 and dialog2 are established) 2) UA3 puts UA1 on hold and does early attended Xfer to UA2 (dialog3 and = dialog4 are in early connected state, UA2 is still ringing). The dialog3/dialog4 INVITE dialogs will use the Name/Number of UA3 in = the From header. So UA2 will allow it as dialog4 is not carrying = anonymous Name/Id. 3) UA3 presses the Xfer button again to complete the early attended = Xfer. Now the identity info of UA1 will be communicated on dialog4 to UA2 in = the UPDATE message say using RPID header. The INVITE dialog4 will not = change the Display Name and Id in the From header as per the UA1's = identity, so it will remain same as original, which is UA3's identity = used during dialog3/dialog4 establishent. The question is the handling of UA1's anonymity by UA2 in the UPDATE = message and affect to the INVITE dialog4. 1. Should UPDATE be responded with 433. How to handle the INVITE dialog4 = as 200 OK is still not sent on dialog4. Based on 433 for UPDATE, b2bua can send CANCEL (With Reason Header = carrying Q.850 cause=3D21 Rejected)to UA2 and UA2 can send 487 on = dialog4.=20 2. Or UPDATE is responded with 433 and later 433 is sent on INVITE = dialog4 resulting in clearing the dialog4 on UA2 and b2bua. Probably 433 = followed by 180 on INVITE dialog will not look appropriate. The dialog1 is already an established dialog so BYE will be sent. The other scenario:- If it has been attended Xfer then dialog4 would have been already = established. So in the same anonymous config the UPDATE could be = responded with 433 and BYE with Reason header carrying SIP Status=3D433 = could be sent from UA2 to b2bua on dialog4. Could we get clarification on this so that standard approach can be = used. Regards, Rajeev -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net] Sent: Monday, August 07, 2006 10:26 AM To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh); Jonathan = Rosenberg (jdrosen); sip@ietf.org Subject: AW: [Sip] updated acr code draft The UAC either should include the identity in the From header instead of = anonymous or don't call again if the user still wants to be anonymous. The UAS should close the transactions. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] > Gesendet: Freitag, 4. August 2006 16:13 > An: Jesske, Roland; Sanjay Sinha (sanjsinh); Jonathan Rosenberg=20 > (jdrosen); sip@ietf.org > Betreff: RE: [Sip] updated acr code draft >=20 >=20 >=20 > The identity in the From header in not the correct party after the=20 > xfer is complete! I still don't see an answer to what should the UAC=20 > do when it gets the 433 response, or what the UAS should do after it=20 > send the 433, basically how does that response impact the INVITE=20 > dialog. >=20 > Thanks, >=20 > Mo >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: Friday, August 04, 2006 4:14 AM > To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh); Jonathan = > Rosenberg (jdrosen); sip@ietf.org > Subject: AW: [Sip] updated acr code draft >=20 > There is a difference between an unavailable identity and a anonymous=20 > identity so that the endpoint can decide. > As a wrote before the From header is a mandatory header. So there must = > an identity in. >=20 > In which scenario this early attended transfer could appear is this=20 > also a interworking case or a pure SIP case? >=20 > What is with the identity I'm registering with? >=20 >=20 > BR >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] > > Gesendet: Donnerstag, 3. August 2006 16:22 > > An: Sanjay Sinha (sanjsinh); Jesske, Roland; Jonathan Rosenberg=20 > > (jdrosen); sip@ietf.org > > Cc: Mohammad Al-Taraireh (maltarai) > > Betreff: RE: [Sip] updated acr code draft > >=20 > >=20 > >=20 > > Another case is a early attended transfer. For example the transfer=20 > > target will get an INVITE without caller id blocking and then an=20 > > UPDATE after the xfer with caller id blocking to change the > display.=20 > > If there is a policy on the endpoint to reject anonymous > calls, what > > should the do in this case? which the question below "what does 433=20 > > mean for mid call UPDATE or reINVITE?" > >=20 > > Thanks, > >=20 > > Mo > >=20 > > -----Original Message----- > > From: Sanjay Sinha (sanjsinh) > > Sent: Thursday, August 03, 2006 9:57 AM > > To: Jesske, R; Jonathan Rosenberg (jdrosen); sip@ietf.org > > Subject: RE: [Sip] updated acr code draft > >=20 > > Scenario is PSTN-SIP interworking. For some cases, display > IE is not > > available in SETUP because some TCAP query is required.=20 > When the query > > is complete, switch sends display IE in a FACILITY message. From=20 > > header is mandatory in INVITE, but calling name and number > is not. So > > Invite is sent without caller-identity which is later > updated with an > > UPDATE/INFO, when the UA gets FACILITY with display information. > >=20 > > Thanks > > Sanjay.=20 > >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: Thursday, August 03, 2006 1:52 AM > > To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen);=20 > > sip@ietf.org > > Subject: AW: [Sip] updated acr code draft > >=20 > > The ACR service itself reacts only on identities that are > put anonymus > > by the user or on behalf on the user. > > So if the restriction is based on other reasons ACR will > not terminate > > the call. > >=20 > > My question to your scenario is in which case an identity is not=20 > > available in an INVITE. The From header is an mandatory > header so the > > >From Header has have an user identity. Or not? > >=20 > > The P-Asserted-Identity is set by an trusted network entity that is=20 > > aware of the user sending that request. > >=20 > > Best Regards > >=20 > > Roland > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > > Gesendet: Mittwoch, 2. August 2006 17:32 > > > An: Jonathan Rosenberg (jdrosen); IETF SIP List > > > Betreff: RE: [Sip] updated acr code draft > > >=20 > > >=20 > > > What about the case in which caller information is not > available at > > > the time INVITE is sent to establish a call, but is > available later > > > and an UPDATE/INFO is sent by UAC to update the caller-id > > information. > > > If UAS rejects UPDATE/INFO with 433, what does it mean for > > the Invite > > > dialog. > > > Should that also be terminated as a result of ACR? > > >=20 > > > Thanks > > > Sanjay > > >=20 > > > -----Original Message----- > > > From: Jonathan Rosenberg (jdrosen) > > > Sent: Monday, July 31, 2006 4:31 PM > > > To: IETF SIP List > > > Subject: [Sip] updated acr code draft > > >=20 > > > I've submitted a minor update to the ACR code draft. Until > > it appears, > > > you can pick it up at: > > >=20 > > > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt > > >=20 > > > the changes are: > > >=20 > > > * replaced P-Asserted-ID with P-Asserted-Identity > > >=20 > > > * added to security considerations section, consideration for=20 > > > anonymizers in the network. Namely, don't retry request on > > receipt of > > > 433 unless explicitly configured to do so by user > > >=20 > > >=20 > > > Thanks, > > > Jonathan R. > > > --=20 > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Cisco Fellow Parsippany, NJ=20 > > > 07054-2711 > > > Cisco Systems > > > jdrosen@cisco.com FAX: =20 > (973) 952-5050 > > > http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > > http://www.cisco.com > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.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://www1.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 > > _______________________________________________ > > Sip mailing list https://www1.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://www1.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 > _______________________________________________ > Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 10:03:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBB6x-0002bf-4V; Thu, 10 Aug 2006 10:02:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBB6v-0002bX-8Q for sip@ietf.org; Thu, 10 Aug 2006 10:02:09 -0400 Received: from mail3.ewr2.n2pcorp.com ([216.53.120.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBB6t-00062r-15 for sip@ietf.org; Thu, 10 Aug 2006 10:02:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] What makes PoC Client IMS compliant Date: Thu, 10 Aug 2006 10:02:06 -0400 Message-ID: <54BC9D88A0ED88479402BDDA9E13EC310981F00F@mail3.ewr2.n2pcorp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What makes PoC Client IMS compliant Thread-Index: Aca8NOYVNk/yc6Q1QeWCI5wbjgCmDwAT7rRA From: "Romel Khan" To: "Rathod Subhashchandra" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rathod, For an understanding of IMS from basic to details, you can for example start of by reading the book: "The IMS: IP Multimedia Concepts and Services, by Miikka Poikselka, Aki Niemi, Hisham Khartabil, Georg Mayer".=20 You should make your PoC compliant with Open Mobile Alliance (OMA). -----Original Message----- From: Rathod Subhashchandra [mailto:rathod@tataelxsi.co.in]=20 Sent: Thursday, August 10, 2006 12:34 AM To: sip@ietf.org Subject: [Sip] What makes PoC Client IMS compliant Hi All, I have developed a PoC client. I am asked that is it a IMS compliant? I don't know what IMS compliant means here. Can anyone help me understanding this question? Is it a valid question? Thanks in advance for a quick reply. Thanks ! Rathod. _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 10:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBB8n-0005RQ-0p; Thu, 10 Aug 2006 10:04:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBB8m-0005RG-9K for sip@ietf.org; Thu, 10 Aug 2006 10:04:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBB8k-0006Am-Kz for sip@ietf.org; Thu, 10 Aug 2006 10:04:04 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Aug 2006 07:03:49 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,110,1154934000"; d="scan'208"; a="35492950:sNHT29886684774" 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.20060308/8.12.11) with ESMTP id k7AE3mDZ012626; Thu, 10 Aug 2006 10:03:48 -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.12.10/8.12.6) with ESMTP id k7AE3me2009638; Thu, 10 Aug 2006 10:03:48 -0400 (EDT) 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); Thu, 10 Aug 2006 10:03:48 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:03:48 -0400 Message-ID: <44DB3CC3.70303@cisco.com> Date: Thu, 10 Aug 2006 10:03:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Rajeev Narang (ranarang)" Subject: Re: [Sip] updated acr code draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 Aug 2006 14:03:48.0291 (UTC) FILETIME=[CD042130:01C6BC85] DKIM-Signature: a=rsa-sha1; q=dns; l=12820; t=1155218628; x=1156082628; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20updated=20acr=20code=20draft |To:=22Rajeev=20Narang=20(ranarang)=22=20; X=v=3Dcisco.com=3B=20h=3DrgimT1XnvyLZmv9CWygP89Ob3d0=3D; b=Ea1EwS1+5iKaUqbnXCW7irZ2nzcE6K4LRY9EjL9E/VEL+tXQmFDD8pzMxSWaXDQbhWUPPlS3 gCbgFJMRsyG/pJKIvj/swKs2m7tD1ECSz8CfCNmb9w562kaL5u9dZHwh; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: sip@ietf.org, "Jesske, R" , "Sanjay Sinha \(sanjsinh\)" , "Mohammad Al-Taraireh \(maltarai\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think the behaviors you describe are all valid ones that the respective UAs may choose to do. And there are other behaviors that are equally valid that might be chosen. I don't think sip/sipping can/should define these, except as example call flows or maybe best practices. This is starting to get pretty deep into feature specification. I think any of the participants in the scenario you describe should be prepared to deal with a variety of responses. As best I can tell, each one can be dealt with on its own without necessarily understanding the bigger picture of what is going on. That is a good thing, since in general none of the players will know the big picture. More inline. Paul Rajeev Narang (ranarang) wrote: > Hi, > > I think Mohammad still hasn't got the clarification. > > The scenario is:- > > UA1----dialog1-------b2bua------dialog4----UA2 > dialog2|dialog3 > | > UA3 > > Say UA1 uses anonymous for its Name/Number. > Say UA2 would reject the anonymous calls. > UA3 is "not" using anonymous for its Name/Number and will "not" reject anonymous calls. > > 1) UA1 calls UA3 (dialog1 and dialog2 are established) > 2) UA3 puts UA1 on hold and does early attended Xfer to UA2 (dialog3 and dialog4 are in early connected state, UA2 is still ringing). > The dialog3/dialog4 INVITE dialogs will use the Name/Number of UA3 in the From header. So UA2 will allow it as dialog4 > is not carrying anonymous Name/Id. > 3) UA3 presses the Xfer button again to complete the early attended Xfer. > > Now the identity info of UA1 will be communicated on dialog4 to UA2 in the UPDATE message say using RPID header. The INVITE dialog4 will not change the Display Name and Id in the From header as per the UA1's identity, so it will remain same as original, which is UA3's identity used during dialog3/dialog4 establishent. > > The question is the handling of UA1's anonymity by UA2 in the UPDATE message and affect to the INVITE dialog4. > > 1. Should UPDATE be responded with 433. That is a choice to be made. It would be equally valid to conclude that one knew the original caller, (and so has someone to *blame*), and decide to trust the wisdom of the person doing the transfer. For instance, suppose U3 is secretary and U4 is boss. The boss may never take anonymous calls, but the secretary does. The secretary acts as the screener for anonymous calls to the boss. > How to handle the INVITE dialog4 as 200 OK is still not sent on dialog4. > Based on 433 for UPDATE, b2bua can send CANCEL (With Reason Header carrying Q.850 cause=21 Rejected)to UA2 and UA2 can send 487 on dialog4. > > 2. Or UPDATE is responded with 433 and later 433 is sent on INVITE dialog4 resulting in clearing the dialog4 on UA2 and b2bua. While UA2 *could* do this, it doesn't make a lot of sense to me. Once the UPDATE is rejected, the dialog continues as it was before. There is no question of the identity of the caller (UA3) and so no reason to fail the call with a 433. User 3 and user 4 can continue to talk - with user 4 complaining to user 3 about trying to transfer an anonymous caller. > Probably 433 followed by 180 on INVITE dialog will not look appropriate. I don't follow. Which dialog? You can't send a 180 to an invite after having sent a 433 to the same invite. I don't see anything odd in other combinations. > The dialog1 is already an established dialog so BYE will be sent. Presumably this will happen if/when the b2bua has nothing else to connect it to. As long as UA3 is in the call I wouldn't expect that. > The other scenario:- > If it has been attended Xfer then dialog4 would have been already established. So in the same anonymous config the > UPDATE could be responded with 433 Certainly. > and BYE with Reason header carrying SIP Status=433 could be sent from UA2 to b2bua on dialog4. As I commented above, I don't see why you would want to do this. From UA2's perspective it still has a call with a known caller. If the b2bua can't maintain that (say because UA3 has sent a BYE) then the b2bua might need to send a BYE - to all the remaining parties. > Could we get clarification on this so that standard approach can be used. As I said above, I don't think there is, or need be, a broad standard for this. Paul > Regards, > Rajeev > > > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: Monday, August 07, 2006 10:26 AM > To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen); sip@ietf.org > Subject: AW: [Sip] updated acr code draft > > The UAC either should include the identity in the From header instead of anonymous or don't call again if the user still wants to be anonymous. > > The UAS should close the transactions. > > Best Regards > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] >> Gesendet: Freitag, 4. August 2006 16:13 >> An: Jesske, Roland; Sanjay Sinha (sanjsinh); Jonathan Rosenberg >> (jdrosen); sip@ietf.org >> Betreff: RE: [Sip] updated acr code draft >> >> >> >> The identity in the From header in not the correct party after the >> xfer is complete! I still don't see an answer to what should the UAC >> do when it gets the 433 response, or what the UAS should do after it >> send the 433, basically how does that response impact the INVITE >> dialog. >> >> Thanks, >> >> Mo >> >> -----Original Message----- >> From: Jesske, R [mailto:R.Jesske@t-com.net] >> Sent: Friday, August 04, 2006 4:14 AM >> To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh); Jonathan >> Rosenberg (jdrosen); sip@ietf.org >> Subject: AW: [Sip] updated acr code draft >> >> There is a difference between an unavailable identity and a anonymous >> identity so that the endpoint can decide. >> As a wrote before the From header is a mandatory header. So there must >> an identity in. >> >> In which scenario this early attended transfer could appear is this >> also a interworking case or a pure SIP case? >> >> What is with the identity I'm registering with? >> >> >> BR >> >> Roland >> >>> -----Ursprüngliche Nachricht----- >>> Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] >>> Gesendet: Donnerstag, 3. August 2006 16:22 >>> An: Sanjay Sinha (sanjsinh); Jesske, Roland; Jonathan Rosenberg >>> (jdrosen); sip@ietf.org >>> Cc: Mohammad Al-Taraireh (maltarai) >>> Betreff: RE: [Sip] updated acr code draft >>> >>> >>> >>> Another case is a early attended transfer. For example the transfer >>> target will get an INVITE without caller id blocking and then an >>> UPDATE after the xfer with caller id blocking to change the >> display. >>> If there is a policy on the endpoint to reject anonymous >> calls, what >>> should the do in this case? which the question below "what does 433 >>> mean for mid call UPDATE or reINVITE?" >>> >>> Thanks, >>> >>> Mo >>> >>> -----Original Message----- >>> From: Sanjay Sinha (sanjsinh) >>> Sent: Thursday, August 03, 2006 9:57 AM >>> To: Jesske, R; Jonathan Rosenberg (jdrosen); sip@ietf.org >>> Subject: RE: [Sip] updated acr code draft >>> >>> Scenario is PSTN-SIP interworking. For some cases, display >> IE is not >>> available in SETUP because some TCAP query is required. >> When the query >>> is complete, switch sends display IE in a FACILITY message. From >>> header is mandatory in INVITE, but calling name and number >> is not. So >>> Invite is sent without caller-identity which is later >> updated with an >>> UPDATE/INFO, when the UA gets FACILITY with display information. >>> >>> Thanks >>> Sanjay. >>> >>> -----Original Message----- >>> From: Jesske, R [mailto:R.Jesske@t-com.net] >>> Sent: Thursday, August 03, 2006 1:52 AM >>> To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen); >>> sip@ietf.org >>> Subject: AW: [Sip] updated acr code draft >>> >>> The ACR service itself reacts only on identities that are >> put anonymus >>> by the user or on behalf on the user. >>> So if the restriction is based on other reasons ACR will >> not terminate >>> the call. >>> >>> My question to your scenario is in which case an identity is not >>> available in an INVITE. The From header is an mandatory >> header so the >>> >From Header has have an user identity. Or not? >>> >>> The P-Asserted-Identity is set by an trusted network entity that is >>> aware of the user sending that request. >>> >>> Best Regards >>> >>> Roland >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] >>>> Gesendet: Mittwoch, 2. August 2006 17:32 >>>> An: Jonathan Rosenberg (jdrosen); IETF SIP List >>>> Betreff: RE: [Sip] updated acr code draft >>>> >>>> >>>> What about the case in which caller information is not >> available at >>>> the time INVITE is sent to establish a call, but is >> available later >>>> and an UPDATE/INFO is sent by UAC to update the caller-id >>> information. >>>> If UAS rejects UPDATE/INFO with 433, what does it mean for >>> the Invite >>>> dialog. >>>> Should that also be terminated as a result of ACR? >>>> >>>> Thanks >>>> Sanjay >>>> >>>> -----Original Message----- >>>> From: Jonathan Rosenberg (jdrosen) >>>> Sent: Monday, July 31, 2006 4:31 PM >>>> To: IETF SIP List >>>> Subject: [Sip] updated acr code draft >>>> >>>> I've submitted a minor update to the ACR code draft. Until >>> it appears, >>>> you can pick it up at: >>>> >>>> http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt >>>> >>>> the changes are: >>>> >>>> * replaced P-Asserted-ID with P-Asserted-Identity >>>> >>>> * added to security considerations section, consideration for >>>> anonymizers in the network. Namely, don't retry request on >>> receipt of >>>> 433 unless explicitly configured to do so by user >>>> >>>> >>>> Thanks, >>>> Jonathan R. >>>> -- >>>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>> Cisco Fellow Parsippany, NJ >>>> 07054-2711 >>>> Cisco Systems >>>> jdrosen@cisco.com FAX: >> (973) 952-5050 >>>> http://www.jdrosen.net PHONE: >> (973) 952-5000 >>>> http://www.cisco.com >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.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://www1.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://www1.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://www1.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://www1.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://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 10:12:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBEg-00015r-86; Thu, 10 Aug 2006 10:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBEe-00015Y-HN for sip@ietf.org; Thu, 10 Aug 2006 10:10:08 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBBEX-0006Qk-3Q for sip@ietf.org; Thu, 10 Aug 2006 10:10:08 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 16:09:51 +0200 Received: from L-AT7568 ([10.193.5.19]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 16:09:51 +0200 Date: Thu, 10 Aug 2006 16:10:33 +0200 From: "Xavier Marjou" To: pkyzivat@cisco.com Subject: Re: [Sip] GRUU and Mid-Dialog Requests Message-ID: X-Mailer: JBMail 3.2 X-OriginalArrivalTime: 10 Aug 2006 14:09:51.0551 (UTC) FILETIME=[A58934F0:01C6BC86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > subsequent (in-dialog) requests are already sent to a specific UA > instance by virtue of the Contact header and the Record-Route for the > dialog. I agree that in-dialog requests are already "sent to a specific UA by virtue of Contact". However, my understanding is that Record-Route headers are "only" required for the GRUU draft because GRUU are advertised in the Contact header fields, and not because of a use-case related requirement. > The point of GRUU is to allow out-of-dialog requests to target a > "specific instance" in the same way that in-dialog requests do. > No more, no less. The point is that additional processing is needed by the current draft in home proxies. To remove this (not-needed?) burden, one could imagine other ways to advertise the GRUU (e.g. a Contact-Gruu header field) instead of advertising it in the Contact header field (e.g. in a 200 of INVITE). The remote user-agent would use this other way for initial requests (e.g. if it wants to send a SUBSCRIBE), without impacting the routing of mid-dialog requests in home proxies. I'm sorry to bring this discussion so late, I just realize this lately. >> Other minor comments: >> >> p11: in the properties that a GRUU must exhibit, add that the host >> part of the URI must be equal to the host of the registrar that owns >> the GRUU. > I don't agree that is a requirement. It could be a different host > part that maps to the same IP, or a different host part that maps > to a different IP but the same server, or it could map to a > different server with access to the same location server. Ok, agreed. However, maybe just rephrase my first proposal by indicating that the host part of the GRUU must be under the responsability of the domain that creates the GRUU. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 10:12:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBDy-0000Se-4T; Thu, 10 Aug 2006 10:09:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBDv-0000SX-TQ for sip@ietf.org; Thu, 10 Aug 2006 10:09:23 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBBDn-0006Og-Lt for sip@ietf.org; Thu, 10 Aug 2006 10:09:19 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2006081014090501300qv0mfe>; Thu, 10 Aug 2006 14:09:05 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k7AE94eY029892 for ; Thu, 10 Aug 2006 10:09:04 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k7AE949U029888; Thu, 10 Aug 2006 10:09:04 -0400 Date: Thu, 10 Aug 2006 10:09:04 -0400 Message-Id: <200608101409.k7AE949U029888@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <003701c6bc26$e32c0590$6d91460a@china.huawei.com> (manjunathwarad@huawei.com) Subject: Re: [Sip] Undefined UAS behaviour in RFC3261 12.2.2 References: <003701c6bc26$e32c0590$6d91460a@china.huawei.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Manjunath Warad Since proxy can retry request on failure response, if UAS rejected a request with failure response and immediate upstream proxy retries to the same UAS and since proxy cannot update CSeq, this scenario is quite possible in the network. No, the proxy cannot "retry" a request, only a UAC can. But if the proxy's sending of the request to one UAS got a failure response, it can send the request to another address (which might go to the same UAS). But that request is a different branch, as evidenced by the fact that the "branch" parameter in the topmost Via header is different. Because of the different branch parameter, the UAS will process the request afresh. The request on a different branch will, of course, have the same CSeq and method. Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 10:21:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBNv-00005C-Bu; Thu, 10 Aug 2006 10:19:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBNu-000057-6j for sip@ietf.org; Thu, 10 Aug 2006 10:19:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBBNs-0006yv-T5 for sip@ietf.org; Thu, 10 Aug 2006 10:19:42 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Aug 2006 07:18:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,111,1154934000"; d="scan'208"; a="35497241:sNHT31863676" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7AEIcu7024516; Thu, 10 Aug 2006 10:18:38 -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.12.10/8.12.6) with ESMTP id k7AEIcdp021982; Thu, 10 Aug 2006 10:18:38 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:18:38 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:18:38 -0400 Message-ID: <44DB403D.2090100@cisco.com> Date: Thu, 10 Aug 2006 10:18:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44DA550E.9020602@cisco.com> <1155216398.7999.58.camel@macbuster.research.nokia.com> In-Reply-To: <1155216398.7999.58.camel@macbuster.research.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 14:18:38.0199 (UTC) FILETIME=[DF715070:01C6BC87] DKIM-Signature: a=rsa-sha1; q=dns; l=2826; t=1155219518; x=1156083518; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Question=20regarding=20instance=20ID=20in=20GRUU=20and=2 0outbound |To:Aki=20Niemi=20; X=v=3Dcisco.com=3B=20h=3DOa/VNwPzdLqO79eqZZ6+DMJpgWI=3D; b=Me6/IQLtJWrpAr8QG/y7QsPpyb9Fq4K9OlnEKF54vWk5JSiwaQ+3kF4VYnu46F/tNGaI+BCD znvQ/z1kuMH3jEykbXBgiW2eN1pcyskD5VigHOdJhocj6XQd/HC2cJBu; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki Niemi wrote: >> I also think its easier for a server to remember an instance ID to GRUU >> binding for a long time, than it is for a client to remember its cookie >> for a long time AND for the server to remember the cookie to GRUU >> mapping for a long time. GRUU persistence would depend on a client >> remembering its cookie basically forever. GRUU currently doesn't require >> persistent storage of any soft state in the client. > > Except it has to persistently store the instance-ID. When the UA moves > to another device, it supposedly needs to take the instance ID with it? Well, that depends on whether you think it makes sense for a UA to move to another device, or whether you thing UAs on different devices are intrinsically different. I don't think there is a single answer to that - it seems to be a religious issue. Some time ago I got into a debate about this with some IMS folk, regarding how this should work on cell phones. I though the instance id ought to move around with the ISIM. Some others had very strong opinions that the instance id should be tied to some id (I forget which one) that is tied to the body of the cell phone rather than the ISIM. I gave up on that argument. It can be an individual choice by the maker of the device and the software that runs on it. In any case, it should often be the case that the instance id can be derived from some piece of unchanging state that the UA has access to. In such cases there is no need for the UA to take extra actions to save it. There are cases when this isn't the true. The most obvious one to me is when a soft phone is installed on a PC. There can be multiple softphones potentially running concurrently on the same PC, but operating and registering independently of one another. In such a case each one must come up with a unique instance id. It may even be the case that the same softphone installation can be used by different users on the PC, each with a unique identity. In these cases there may be a need to explicitly persist the instance id in a store that properly correlated with the particular notion of "instance" that makes sense under the circumstances. > There's really no difference here to the (implicit) requirement on a UA > that the UA has to store the user credentials, per AOR, in persistent > storage, forever. > > Unless a blackphone intends to query a digest password upon every > registration after a reboot cycle? That probably wouldn't work, > especially with a numeric keypad and an alphanumeric password. Or at > least I would toss that phone out the window pretty quickly. ;) The black phone can simply derive the instance id from its serial number or some other convenient and unchanging piece of info. Paul _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 10:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBZS-00014Z-I6; Thu, 10 Aug 2006 10:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBZQ-00014G-5X for sip@ietf.org; Thu, 10 Aug 2006 10:31:36 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBBZO-0007hs-Sc for sip@ietf.org; Thu, 10 Aug 2006 10:31:36 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Aug 2006 10:31:34 -0400 X-IronPort-AV: i="4.08,111,1154923200"; d="scan'208"; a="96044197:sNHT26326976" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7AEVYXm000419; Thu, 10 Aug 2006 10:31:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7AEVYdp026236; Thu, 10 Aug 2006 10:31:34 -0400 (EDT) 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); Thu, 10 Aug 2006 10:31:34 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:31:33 -0400 Message-ID: <44DB4345.5050109@cisco.com> Date: Thu, 10 Aug 2006 10:31:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Xavier Marjou Subject: Re: [Sip] GRUU and Mid-Dialog Requests References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 14:31:33.0892 (UTC) FILETIME=[ADCAAC40:01C6BC89] DKIM-Signature: a=rsa-sha1; q=dns; l=2579; t=1155220294; x=1156084294; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20GRUU=20and=20Mid-Dialog=20Requests |To:Xavier=20Marjou=20; X=v=3Dcisco.com=3B=20h=3DBHfEp4ZxQe5icuUoxUyoBEiHrTI=3D; b=qeQfYhYoLnEAZ3t67FX7gUsTMl6+mgmiGAuwWq4WtH1/KFDVRwdwKnvi49RilcVEdSAZG/1e LbdcdLlgE3dBbkxZHNV0c8ntCWckour279tzgwtedNkaI+CKS38gaprI; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Xavier Marjou wrote: >> subsequent (in-dialog) requests are already sent to a specific UA >> instance by virtue of the Contact header and the Record-Route for the >> dialog. > > I agree that in-dialog requests are already "sent to a specific UA by > virtue of Contact". However, my understanding is that Record-Route headers > are "only" required for the GRUU draft because GRUU are advertised in the > Contact header fields, and not because of a use-case related requirement. > >> The point of GRUU is to allow out-of-dialog requests to target a >> "specific instance" in the same way that in-dialog requests do. >> No more, no less. > > The point is that additional processing is needed by the current draft in > home proxies. To remove this (not-needed?) burden, one could imagine other > ways to advertise the GRUU (e.g. a Contact-Gruu header field) instead of > advertising it in the Contact header field (e.g. in a 200 of INVITE). The > remote user-agent would use this other way for initial requests (e.g. if it > wants to send a SUBSCRIBE), without impacting the routing of mid-dialog > requests in home proxies. What you (I think) are suggesting was considered long ago. But it was discarded for a variety of reasons. Jonathan can probably dredge them out of his memory better than I can. In any case, no matter how it is done, when a UA doesn't have an address of its own with the gruu property, then it will need to get one from some server elsewhere. That server will then have to take action every time that gruu is used. At best you could avoid a small amount of work on in-dialog requests. But chances are the home proxy would still have to record-route, because in-dialog requests would have to transit some box that has addressability to the UA. Paul > I'm sorry to bring this discussion so late, I just realize this lately. > > >>> Other minor comments: >>> >>> p11: in the properties that a GRUU must exhibit, add that the host >>> part of the URI must be equal to the host of the registrar that owns >>> the GRUU. > >> I don't agree that is a requirement. It could be a different host >> part that maps to the same IP, or a different host part that maps >> to a different IP but the same server, or it could map to a >> different server with access to the same location server. > > Ok, agreed. However, maybe just rephrase my first proposal by indicating > that the host part of the GRUU must be under the responsability of the > domain that creates the GRUU. > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 10:58:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBxw-0001xA-7t; Thu, 10 Aug 2006 10:56:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBxu-0001wq-KC for sip@ietf.org; Thu, 10 Aug 2006 10:56:54 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBBxr-00016l-JZ for sip@ietf.org; Thu, 10 Aug 2006 10:56:54 -0400 Received: from [131.161.248.92] (open-131-161-248-92.cliq.com [131.161.248.92]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k7AEukF21962; Thu, 10 Aug 2006 07:56:46 -0700 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1306@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F1306@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound issues: slides 9 and 10 - Why does every proxy need to support outbound? Date: Thu, 10 Aug 2006 07:57:12 -0700 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 23:19, Christer Holmberg ((JO/LMF)) wrote: > > Hi Rohan, > >> Christer, please read the slides. The issue we are trying to detect >> is > described in slide 9. The UA sends through an >> outbound-proxy that adds a Path, but does not support outbound. The > registrar needs to detect that. > > I am not arguing against that. I am simply commenting on the proposed > mechanisms that YOU wrote. > > YOU said that ALL Path headers (not only the one inserted by the > outbound proxy) must contain the ob parameter, and I question that. > > YOU said that the registrar must start comparing Vias with Paths, and I > propose a way to avoid that. Right. You should be able to compare only the first Path and the first Via. I guess there is no reason for the other Path headers to have ;ob. thanks, -rohan > Regards, > > Christer > > > > On Aug 9, 2006, at 9:46, Christer Holmberg ((JO/LMF)) wrote: >> >> Hi, >> >> A couple of questions: >> >>> The issues on slide 9 (how does a registrar verify that an edge proxy >> supports outbound) and slide 10 (what does >"Supported: outbound" >> mean) deal with detecting that all the required hops support outbound. > >> Slide >>> 9 specifically uncovered a problem with outbound proxies that add a >> Path URI but don't include a flow token. >>> >>> The proposed solution is as follows. If a proxy inserts a Path >>> header >> with a flow token consistent with the rules d >>> escribed in outbound, it MUST add the ;ob parameter to the proxy URI >> that has the flow token. >>> >>> The registrar verifies that any Path header URIs contain the ;ob >> parameter. If there are any Path URIs without the ob >>> parameter, the registrar does not return Supported: outbound. >> >> [CHH] Why would every Path header need to contain the ;ob parameter? >> The >> REGISTER request may traverse, in addition to the outbound proxy, >> multiple proxies which insert a Path header. Do all these proxies >> really need to support outbound? >> >>> Furthermore, the registrar needs to check that the first hop after >>> the >> UAC is represented in the Path list (unless the >>> registrar recognizes that the first hop after the UAC is in the same >> domain and doesn't need to include Path URIs with a >>> flow token). Note that this implies that whatever the proxy puts in >> the Via (IP address or FQDN), it must put the same >>> hostname in the Path header (but there is no need for a complete URI >> comparison). If the first hop is not correctly >>> represented, the registrar ignores the reg-id parameter and does not >> return Supported: outbound. >> >> [CHH] Isn't it much easier to mandate the outbound proxy to always >> insert a Path header? >> >> OR, another possibility is that the outbound proxy, if it detects that > >> the UAC supports outbound, insert some option-tag of itself in the >> Supported header, to indicate to the registrar that it supports >> outbound. Then the registrar does not need start looking at the Path >> headers. >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> >> The implication of this is that an outbound-proxy that supports >> outbound needs to support Path and flow tokens for registrations to >> all foreign domains. Inside the same domain, the first-hop proxy and >> the registrar can still use Path to communicate with each other, but >> they can use some other private mechanism to disaggregate this >> functionality. >> >> thanks, >> -rohan >> >> >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 11:00:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBzy-0004gf-Id; Thu, 10 Aug 2006 10:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBzw-0004gW-9J for sip@ietf.org; Thu, 10 Aug 2006 10:59:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBBzt-0001JP-AA for sip@ietf.org; Thu, 10 Aug 2006 10:59:00 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2006 07:58:57 -0700 X-IronPort-AV: i="4.08,111,1154934000"; d="scan'208"; a="439977920:sNHT45807960" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7AEwsgw025796; Thu, 10 Aug 2006 07:58:55 -0700 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7AEwrte001403; Thu, 10 Aug 2006 14:58:54 GMT Received: from xmb-blr-418.apac.cisco.com ([64.104.140.147]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 20:28:53 +0530 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 Subject: RE: [Sip] updated acr code draft Date: Thu, 10 Aug 2006 20:28:52 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] updated acr code draft Thread-Index: Aca8hc/P9Rd08pq+SKCBDjy+6tFpnQAAqSKA From: "Rajeev Narang \(ranarang\)" To: "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 10 Aug 2006 14:58:53.0573 (UTC) FILETIME=[7F1E2350:01C6BC8D] DKIM-Signature: a=rsa-sha1; q=dns; l=15374; t=1155221936; x=1156085936; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ranarang@cisco.com; z=From:=22Rajeev=20Narang=20\(ranarang\)=22=20 |Subject:RE=3A=20[Sip]=20updated=20acr=20code=20draft; X=v=3Dcisco.com=3B=20h=3DF/nY3Q2j2zfj8q7tBnYC2Qs89CM=3D; b=aKHn42jMZbq5AI6ieBU5TXKo9dPjAPAHfJp5VavIenCu+iHrlq3PW8t4ItmrNvZPxl/OCwVh PgcOThbRJCiWJlthUkEr5qOaYbJJ2BpzT3jdk3eJv2ZE5D8vI81WFQ/M; Authentication-Results: sj-dkim-1.cisco.com; header.From=ranarang@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec Cc: sip@ietf.org, "Jesske, R" , "Sanjay Sinha \(sanjsinh\)" , "Mohammad Al-Taraireh \(maltarai\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, Please see response inline...[RAJEEV] -----Original Message----- From: Paul Kyzivat (pkyzivat)=20 Sent: Thursday, August 10, 2006 7:34 PM To: Rajeev Narang (ranarang) Cc: Jonathan Rosenberg (jdrosen); sip@ietf.org; Jesske, R; Sanjay Sinha = (sanjsinh); Mohammad Al-Taraireh (maltarai) Subject: Re: [Sip] updated acr code draft I think the behaviors you describe are all valid ones that the = respective UAs may choose to do. And there are other behaviors that are = equally valid that might be chosen. I don't think sip/sipping can/should = define these, except as example call flows or maybe best practices. This = is starting to get pretty deep into feature specification. I think any of the participants in the scenario you describe should be = prepared to deal with a variety of responses. As best I can tell, each = one can be dealt with on its own without necessarily understanding the = bigger picture of what is going on. That is a good thing, since in = general none of the players will know the big picture. More inline. Paul Rajeev Narang (ranarang) wrote: > Hi, >=20 > I think Mohammad still hasn't got the clarification. >=20 > The scenario is:- >=20 > UA1----dialog1-------b2bua------dialog4----UA2 > dialog2|dialog3 > | > UA3 >=20 > Say UA1 uses anonymous for its Name/Number. > Say UA2 would reject the anonymous calls. > UA3 is "not" using anonymous for its Name/Number and will "not" reject = anonymous calls. > =20 > 1) UA1 calls UA3 (dialog1 and dialog2 are established) > 2) UA3 puts UA1 on hold and does early attended Xfer to UA2 (dialog3 = and dialog4 are in early connected state, UA2 is still ringing). > The dialog3/dialog4 INVITE dialogs will use the Name/Number of UA3 in=20 > the From header. So UA2 will allow it as dialog4 is not carrying = anonymous Name/Id. > 3) UA3 presses the Xfer button again to complete the early attended = Xfer. >=20 > Now the identity info of UA1 will be communicated on dialog4 to UA2 in = the UPDATE message say using RPID header. The INVITE dialog4 will not = change the Display Name and Id in the From header as per the UA1's = identity, so it will remain same as original, which is UA3's identity = used during dialog3/dialog4 establishent. >=20 > The question is the handling of UA1's anonymity by UA2 in the UPDATE = message and affect to the INVITE dialog4. >=20 > 1. Should UPDATE be responded with 433. That is a choice to be made. It would be equally valid to conclude that = one knew the original caller, (and so has someone to *blame*), and = decide to trust the wisdom of the person doing the transfer. For instance, suppose U3 is secretary and U4 is boss. The boss may never = take anonymous calls, but the secretary does. The secretary acts as the = screener for anonymous calls to the boss. [RAJEEV: This is a good example/explanation. ] > How to handle the INVITE dialog4 as 200 OK is still not sent on = dialog4. > Based on 433 for UPDATE, b2bua can send CANCEL (With Reason Header = carrying Q.850 cause=3D21 Rejected)to UA2 and UA2 can send 487 on = dialog4.=20 >=20 > 2. Or UPDATE is responded with 433 and later 433 is sent on INVITE = dialog4 resulting in clearing the dialog4 on UA2 and b2bua. While UA2 *could* do this, it doesn't make a lot of sense to me. Once = the UPDATE is rejected, the dialog continues as it was before. There is = no question of the identity of the caller (UA3) and so no reason to fail = the call with a 433. User 3 and user 4 can continue to talk - with user 4 complaining to user 3 about trying to transfer an anonymous caller. [RAJEEV:- In early attended Xfer case, user3 and user2 will not get chance to talk = as the Xfer will take place after 180 Ringing from UA2 to b2bua (on = dialog4) and b2bua to UA3 (on dialog3) and before 200 OK i.e user2 (UA2) = is still "not" offhook. Actually the point is if b2bua/ua2 wants to implement a policy to not = allow such transfers from anonymous user to user restricting anonymous = calls, then can UPDATE/433 be handled by sending a CANCEL from b2bua on = dialog4 to UA2. I think there is no clear specification on that, so we = wanted to get a clarification on this if that is good to do from b2bua. Also if UA2 wants to clear the call based on its local policy for not = allowing such Xfer then what should be sent on INVITE dialog4, which is = in early connected state. ] > Probably 433 followed by 180 on INVITE dialog will not look = appropriate. I don't follow. Which dialog? You can't send a 180 to an invite after = having sent a 433 to the same invite. I don't see anything odd in other = combinations. [RAJEEV:- This is dialog4 from b2bua to UA2. For early attended Xfer, the UA2 = would have sent 100/180 on receiving INVITE. While 180 is received by = UA3 on dialog3, the Xfer button press again will do the Xfer.=20 Next b2bua will send an UPDATE on dialog4 to UA2 (with Name/Id privacy = info about UA1), for which 433 could be sent from UA2. So 433 on INVITE = dialog could be sent, but that may be odd. ] > The dialog1 is already an established dialog so BYE will be sent. Presumably this will happen if/when the b2bua has nothing else to = connect it to. As long as UA3 is in the call I wouldn't expect that. [RAJEEV:- It could be based on the policy for the b2bua whether to allow such Xfer = or not. I agree if the policy is to allow such Xfer then BYE shouldn't = be sent. ] > The other scenario:- > If it has been attended Xfer then dialog4 would have been already=20 > established. So in the same anonymous config the UPDATE could be=20 > responded with 433 Certainly. > and BYE with Reason header carrying SIP Status=3D433 could be sent = from UA2 to b2bua on dialog4. As I commented above, I don't see why you would want to do this. From = UA2's perspective it still has a call with a known caller. If the b2bua = can't maintain that (say because UA3 has sent a BYE) then the b2bua = might need to send a BYE - to all the remaining parties. [RAJEEV:- For Attended Xfer i.e dialog4 got established and UA2 user talked with = UA3 user, if UA2 independently wants to take the decision that it will = not allow the Xfer from anonymous users based on the local policy then = probably it may send BYE after UPDATE/433 handling. But a policy could be relaxed by UA2 in this case because UA3 user = already talked with UA2 user and got the permission verbally, so UA2 may = continue with the Invite dialog by sending 200 OK. Thanks, Rajeev ] > Could we get clarification on this so that standard approach can be = used. As I said above, I don't think there is, or need be, a broad standard = for this. Paul > Regards, > Rajeev >=20 >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: Monday, August 07, 2006 10:26 AM > To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh); Jonathan = > Rosenberg (jdrosen); sip@ietf.org > Subject: AW: [Sip] updated acr code draft >=20 > The UAC either should include the identity in the From header instead = of anonymous or don't call again if the user still wants to be = anonymous. >=20 > The UAS should close the transactions. >=20 > Best Regards >=20 > Roland >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] >> Gesendet: Freitag, 4. August 2006 16:13 >> An: Jesske, Roland; Sanjay Sinha (sanjsinh); Jonathan Rosenberg=20 >> (jdrosen); sip@ietf.org >> Betreff: RE: [Sip] updated acr code draft >> >> >> >> The identity in the From header in not the correct party after the=20 >> xfer is complete! I still don't see an answer to what should the UAC=20 >> do when it gets the 433 response, or what the UAS should do after it=20 >> send the 433, basically how does that response impact the INVITE=20 >> dialog. >> >> Thanks, >> >> Mo >> >> -----Original Message----- >> From: Jesske, R [mailto:R.Jesske@t-com.net] >> Sent: Friday, August 04, 2006 4:14 AM >> To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh);=20 >> Jonathan Rosenberg (jdrosen); sip@ietf.org >> Subject: AW: [Sip] updated acr code draft >> >> There is a difference between an unavailable identity and a anonymous = >> identity so that the endpoint can decide. >> As a wrote before the From header is a mandatory header. So there=20 >> must an identity in. >> >> In which scenario this early attended transfer could appear is this=20 >> also a interworking case or a pure SIP case? >> >> What is with the identity I'm registering with? >> >> >> BR >> >> Roland >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] >>> Gesendet: Donnerstag, 3. August 2006 16:22 >>> An: Sanjay Sinha (sanjsinh); Jesske, Roland; Jonathan Rosenberg=20 >>> (jdrosen); sip@ietf.org >>> Cc: Mohammad Al-Taraireh (maltarai) >>> Betreff: RE: [Sip] updated acr code draft >>> >>> >>> >>> Another case is a early attended transfer. For example the transfer=20 >>> target will get an INVITE without caller id blocking and then an=20 >>> UPDATE after the xfer with caller id blocking to change the >> display.=20 >>> If there is a policy on the endpoint to reject anonymous >> calls, what >>> should the do in this case? which the question below "what does 433=20 >>> mean for mid call UPDATE or reINVITE?" >>> >>> Thanks, >>> >>> Mo >>> >>> -----Original Message----- >>> From: Sanjay Sinha (sanjsinh) >>> Sent: Thursday, August 03, 2006 9:57 AM >>> To: Jesske, R; Jonathan Rosenberg (jdrosen); sip@ietf.org >>> Subject: RE: [Sip] updated acr code draft >>> >>> Scenario is PSTN-SIP interworking. For some cases, display >> IE is not >>> available in SETUP because some TCAP query is required.=20 >> When the query >>> is complete, switch sends display IE in a FACILITY message. From=20 >>> header is mandatory in INVITE, but calling name and number >> is not. So >>> Invite is sent without caller-identity which is later >> updated with an >>> UPDATE/INFO, when the UA gets FACILITY with display information. >>> >>> Thanks >>> Sanjay.=20 >>> >>> -----Original Message----- >>> From: Jesske, R [mailto:R.Jesske@t-com.net] >>> Sent: Thursday, August 03, 2006 1:52 AM >>> To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen);=20 >>> sip@ietf.org >>> Subject: AW: [Sip] updated acr code draft >>> >>> The ACR service itself reacts only on identities that are >> put anonymus >>> by the user or on behalf on the user. >>> So if the restriction is based on other reasons ACR will >> not terminate >>> the call. >>> >>> My question to your scenario is in which case an identity is not=20 >>> available in an INVITE. The From header is an mandatory >> header so the >>> >From Header has have an user identity. Or not? >>> >>> The P-Asserted-Identity is set by an trusted network entity that is=20 >>> aware of the user sending that request. >>> >>> Best Regards >>> >>> Roland >>> >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] >>>> Gesendet: Mittwoch, 2. August 2006 17:32 >>>> An: Jonathan Rosenberg (jdrosen); IETF SIP List >>>> Betreff: RE: [Sip] updated acr code draft >>>> >>>> >>>> What about the case in which caller information is not >> available at >>>> the time INVITE is sent to establish a call, but is >> available later >>>> and an UPDATE/INFO is sent by UAC to update the caller-id >>> information. >>>> If UAS rejects UPDATE/INFO with 433, what does it mean for >>> the Invite >>>> dialog. >>>> Should that also be terminated as a result of ACR? >>>> >>>> Thanks >>>> Sanjay >>>> >>>> -----Original Message----- >>>> From: Jonathan Rosenberg (jdrosen) >>>> Sent: Monday, July 31, 2006 4:31 PM >>>> To: IETF SIP List >>>> Subject: [Sip] updated acr code draft >>>> >>>> I've submitted a minor update to the ACR code draft. Until >>> it appears, >>>> you can pick it up at: >>>> >>>> http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt >>>> >>>> the changes are: >>>> >>>> * replaced P-Asserted-ID with P-Asserted-Identity >>>> >>>> * added to security considerations section, consideration for=20 >>>> anonymizers in the network. Namely, don't retry request on >>> receipt of >>>> 433 unless explicitly configured to do so by user >>>> >>>> >>>> Thanks, >>>> Jonathan R. >>>> --=20 >>>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>> Cisco Fellow Parsippany, NJ=20 >>>> 07054-2711 >>>> Cisco Systems >>>> jdrosen@cisco.com FAX: =20 >> (973) 952-5050 >>>> http://www.jdrosen.net PHONE:=20 >> (973) 952-5000 >>>> http://www.cisco.com >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.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 >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.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 >>>> >>> _______________________________________________ >>> Sip mailing list https://www1.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 >>> >>> _______________________________________________ >>> Sip mailing list https://www1.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 >>> >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 11:31:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBCTG-00041I-0B; Thu, 10 Aug 2006 11:29:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBCTE-000418-K6 for sip@ietf.org; Thu, 10 Aug 2006 11:29:16 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBCTD-0004bg-4s for sip@ietf.org; Thu, 10 Aug 2006 11:29:16 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7AETDac001084; Thu, 10 Aug 2006 17:29:13 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 18:29:12 +0300 Received: from esdhcp03573.research.nokia.com ([172.21.35.73]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Aug 2006 18:29:11 +0300 Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound From: Aki Niemi To: ext Paul Kyzivat In-Reply-To: <44DB36B4.6010103@cisco.com> References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44D91E3C.6020204@softarmor.com> <1155113399.16458.27.camel@macbuster.research.nokia.com> <2CB5B0AC-F06D-4E9B-83B7-299146798CB1@softarmor.com> <44DA120A.1090107@cisco.com> <1155215554.7999.43.camel@macbuster.research.nokia.com> <44DB36B4.6010103@cisco.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Thu, 10 Aug 2006 18:29:11 +0300 Message-Id: <1155223751.7999.114.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 15:29:11.0088 (UTC) FILETIME=[BA70EB00:01C6BC91] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org to, 2006-08-10 kello 09:37 -0400, ext Paul Kyzivat kirjoitti: > > Aki Niemi wrote: > > ke, 2006-08-09 kello 12:49 -0400, ext Paul Kyzivat kirjoitti: > >> In theory they could use different techniques, though the value of that > >> seems dubious to me. If they both use the same id, then it has to meet > >> both of their needs. As things stand it does. If it were to be changed > >> to a cookie supplied by the registrar, then its unclear if it could as > >> well meet both sets of needs. > > > > Like I responded to Dean, the issue of who generates the unique > > identifier is completely orthogonal to the issue of having to store it > > "indefinitely". > > > > You can just as easily lose track of client provided instance IDs at the > > registrar as you do those you created yourself. But I feel a lot more > > comfortable giving UAs handles from my own private pool. > > There is a huge difference. The UA can remember is instance id or not as > it sees fit. In that regard it controls its own destiny. If it forgets, > then old gruus stop working. It can make its own decision if that is > acceptable, bad, or intended. > > With the current scheme, the registrar only needs to remember the > instance ids while a registration is active. If it can't manage that, > then it is incompetent to be a registrar. It doesn't have to remember > them longer. That is a good thing, because it is not in a position to > decide how long one should remain valid. Hmm.. Then I must be reading the specs wrong. To my reading, the registrar needs to store the instance ID and use it as a search key into allowed GRUUs for the AOR. If the registrar didn't need to remember the instance-id -> GRUU mapping indefinitely to make the GRUU always be assigned to the same instance, then I don't understand why the UA bothers offering its "+sip.instance" to the registrar in the first place? In fact, isn't the GRUU effectively the "cookie" here? Or is the intention, in fact, that the UA knows nothing whatsoever of its assigned GRUUs, but uses the instance-ID to fetch the GRUUs from the registrar in the first REGISTER? Ugh. What you say holds true for sip-outbound, though, which is partly the problem I was having with instance-id. In outbound, it is really only a *recommendation* that the instance-id survives a reboot; if it doesn't, nothing breaks, and the old flow will simply be garbage-collected sooner or later anyway by the registrar. I think there is a disconnect here somewhere (maybe me), because to me, by your description of the persistence of GRUU, the following things need to happen: - A UA generates a GRUU - The UA remembers the GRUU as long as it seems fit - The registrar remembers the GRUU indefinitely - The registrar allows registrations from the same AOR to the GRUU So effectively, the GRUU *is* the cookie here, and this really boils down to whether the UA remembers its GRUUs, or just its instance-ID. I'd argue it better remember its GRUUs. Otherwise this demented UA will be receiving lots of requests with no idea why it's receiving them, and what these different grids are supposed to do. > Maybe you would just prefer the current scheme, except that the > registrar is the only source of instance ids. I can see no advantage in > that over the current scheme. And I do see considerable disadvantage. I guess, but now I'm just confused. ;) Cheers, Aki -- Aki Niemi Nokia Research Center _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 12:10:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBD5R-0001HQ-US; Thu, 10 Aug 2006 12:08:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBD5P-0001Ff-RW for sip@ietf.org; Thu, 10 Aug 2006 12:08:44 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBD5O-0000pq-EV for sip@ietf.org; Thu, 10 Aug 2006 12:08:43 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7AG8YA1015020; Thu, 10 Aug 2006 19:08:40 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 19:08:16 +0300 Received: from esdhcp03573.research.nokia.com ([172.21.35.73]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Aug 2006 19:08:16 +0300 Subject: RE: [Sip] Question regarding instance ID in GRUU and outbound From: Aki Niemi To: "ext Elwell, John" In-Reply-To: <50B1CBA96870A34799A506B2313F26670998BF40@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F26670998BF40@ntht201e.siemenscomms.co.uk> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Thu, 10 Aug 2006 19:08:15 +0300 Message-Id: <1155226095.7999.147.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 16:08:16.0257 (UTC) FILETIME=[30454F10:01C6BC97] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org to, 2006-08-10 kello 08:09 +0100, ext Elwell, John kirjoitti: > Furthermore, a UA that is in the habit of registering in more than one > domain (in support of mobility, hot-desking, or whatever) would need to > remember multiple cookies - gets complicated. No more complicated than storing user credentials per AoR (and yes, all of the UAs I've ever used -- black, soft, hard, mobile, or otherwise -- do this already. Plus (I assume you're talking about sip-outbound) I consider the persistent storage of the flow identifier as only a recommended courtesy in helping the registrar invalidate flows that would otherwise be left dangling because of a UA reboot. Cheers, Aki -- Aki Niemi Nokia Research Center _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 12:56:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBDoJ-0000hU-J3; Thu, 10 Aug 2006 12:55:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBDoH-0000hN-KO for sip@ietf.org; Thu, 10 Aug 2006 12:55:05 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBDoG-0003UC-8j for sip@ietf.org; Thu, 10 Aug 2006 12:55:05 -0400 Received: from [206.176.144.213] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7AGvEld004205 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 10 Aug 2006 11:57:15 -0500 In-Reply-To: <1155216398.7999.58.camel@macbuster.research.nokia.com> References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44DA550E.9020602@cisco.com> <1155216398.7999.58.camel@macbuster.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound Date: Thu, 10 Aug 2006 11:55:00 -0500 To: Aki Niemi X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 10, 2006, at 8:26 AM, Aki Niemi wrote: > > Except it has to persistently store the instance-ID. When the UA moves > to another device, it supposedly needs to take the instance ID with > it? > As I understand it the new the other device is a different instance, so it's a new GRUU. > There's really no difference here to the (implicit) requirement on > a UA > that the UA has to store the user credentials, per AOR, in persistent > storage, forever. Yes, there is. The instance-ID can be determined algorithmically from things known to the device. The user credentials cannot. Now, things do get a little fuzzy. Let's take, for example, a multiple-user UA running on a general- purpose computer. It supports N different UA instances, so it devises N-different instance IDs. A naive approach might take the primary MAC address and concatenate 1 for the first ID, 2, for the second ID, and so on. So far, so good. Now, let's say that instance 1 goes to Alice, and Alice has made calls that would result in somebody using her GRUU. The UA loses its hard drive and gets reinstalled. This time, instance 1 is assigned to Bob. Is the GRUU factory confused by this? No, as has been pointed out, because the GRUU is assembled from both the AOR and the instance ID, and we assuming Alice and Bob did not also exchange AORs. Of course, if we REALLY wanted the instance ID to be locally unique, we could have synthesized it using a time-date stamp instead of starting with 1. Thus, following the reinstall, we get all new instance-IDs and all new GRUUs with no potential for overlap or confusion. Of course, this makes the pre-installation GRUUs no longer valid, but they MIGHT not have been valid anyhow. So which approach does the most damage to the immortality of a GRUU? I'd argue that they're equal -- GRUUs aren't really eternal, just relatively long-lived. The important thing is that when we cross a GRUU "generation boundary" is that the GRUU of the next generation are either exactly the same as their ancestors (in effect, continuing the same GRUU), or that they are completely distinct from their ancestors, such that each is unique. Scenarios where post-reinstall, the GRUU for Alice's UA is the same as the GRUU for Bob's UA before reinstall would violate this principle, and must be prevented. Fortunately, we seem to have met this criteria with the current mechanism. -- dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 12:57:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBDoj-00012C-ET; Thu, 10 Aug 2006 12:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBDoi-0000zs-1x for sip@ietf.org; Thu, 10 Aug 2006 12:55:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBDoc-0003Wa-KK for sip@ietf.org; Thu, 10 Aug 2006 12:55:32 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Aug 2006 12:55:26 -0400 X-IronPort-AV: i="4.08,111,1154923200"; d="scan'208"; a="96073249:sNHT26939968" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7AGtQmb016923; Thu, 10 Aug 2006 12:55:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7AGtPdp009220; Thu, 10 Aug 2006 12:55:25 -0400 (EDT) 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); Thu, 10 Aug 2006 12:55:25 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 12:55:25 -0400 Message-ID: <44DB64FB.8020308@cisco.com> Date: Thu, 10 Aug 2006 12:55:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44D91E3C.6020204@softarmor.com> <1155113399.16458.27.camel@macbuster.research.nokia.com> <2CB5B0AC-F06D-4E9B-83B7-299146798CB1@softarmor.com> <44DA120A.1090107@cisco.com> <1155215554.7999.43.camel@macbuster.research.nokia.com> <44DB36B4.6010103@cisco.com> <1155223751.7999.114.camel@macbuster.research.nokia.com> In-Reply-To: <1155223751.7999.114.camel@macbuster.research.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 16:55:25.0328 (UTC) FILETIME=[C6874900:01C6BC9D] DKIM-Signature: a=rsa-sha1; q=dns; l=4367; t=1155228926; x=1156092926; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Question=20regarding=20instance=20ID=20in=20GRUU=20and=2 0outbound |To:Aki=20Niemi=20; X=v=3Dcisco.com=3B=20h=3DOa/VNwPzdLqO79eqZZ6+DMJpgWI=3D; b=tAE3E/ZPsqa8DEDxoYrXdmq+WZAaxQn2DbvNjw+rbt8WioR8DFIdJ+gfSFy+zMJWm9kV98E6 z/LTRdQtlG+Ucfx0NcUsDulKiS+nuVWEJ/gARLxarVXJVAMcqZ1Fws8u; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki Niemi wrote: >> With the current scheme, the registrar only needs to remember the >> instance ids while a registration is active. If it can't manage that, >> then it is incompetent to be a registrar. It doesn't have to remember >> them longer. That is a good thing, because it is not in a position to >> decide how long one should remain valid. > > Hmm.. Then I must be reading the specs wrong. To my reading, the > registrar needs to store the instance ID and use it as a search key into > allowed GRUUs for the AOR. There is discretion on how the registrar implements GRUU. It *could* implement it in a way that requires storage. But it is also possible to implement in a way that does not. The (actually *a*) way to do this without storage is by the registrar placing the instance id, or some invertable mapping of it, and the AOR, or some invertable mapping of it, into the gruu. The draft defines the "opaque" parameter for this purpose. As long as the instance id and AOR can be recovered from the gruu by the home proxy, and some UA is registered to the AOR with the instance id, requests addressed to the gruu can be routed. > If the registrar didn't need to remember the instance-id -> GRUU mapping > indefinitely to make the GRUU always be assigned to the same instance, > then I don't understand why the UA bothers offering its "+sip.instance" > to the registrar in the first place? In fact, isn't the GRUU effectively > the "cookie" here? > > Or is the intention, in fact, that the UA knows nothing whatsoever of > its assigned GRUUs, but uses the instance-ID to fetch the GRUUs from the > registrar in the first REGISTER? Ugh. Yes, exactly. The UA is presumed to remember (or be able to reconstruct) its instance id, but not its GRUU. Each time it registers afresh, it receives its gruu. If the registrar is compatible with prior ones for the same AOR, then the gruu returned will normally be the same as previously. (This is a matter of applying a constant function to the same parameters and so getting the same result.) In that case, any gruus that happen to have been saved by others will work and reach the newly reregistered UA. > What you say holds true for sip-outbound, though, which is partly the > problem I was having with instance-id. In outbound, it is really only a > *recommendation* that the instance-id survives a reboot; if it doesn't, > nothing breaks, and the old flow will simply be garbage-collected sooner > or later anyway by the registrar. > > I think there is a disconnect here somewhere (maybe me), because to me, > by your description of the persistence of GRUU, the following things > need to happen: > > - A UA generates a GRUU The UA asks the registrar to assign it a gruu > - The UA remembers the GRUU as long as it seems fit The UA only has to remember it as long as it remains registered, so it can use it as the contact address of dialogs it is involved in. > - The registrar remembers the GRUU indefinitely The registrar only needs to remember how to reconstruct the AOR and the instance id from gruus it constructed in the past. > - The registrar allows registrations from the same AOR to the GRUU I don't understand the above. > So effectively, the GRUU *is* the cookie here, The gruu is more than a cookie. If the registrar follows the suggested implementation, then the "opaque" parameter is a cookie for the registrar. > and this really boils > down to whether the UA remembers its GRUUs, or just its instance-ID. I'd > argue it better remember its GRUUs. If the UA registers multiple AORs then it can have multiple gruus, but it need have only one instance id. And it can be derived from something that it already has permanently, rather than being saved. That seems way simpler to me. > Otherwise this demented UA will be receiving lots of requests with no > idea why it's receiving them, and what these different grids are > supposed to do. Huh? Say more. Paul >> Maybe you would just prefer the current scheme, except that the >> registrar is the only source of instance ids. I can see no advantage in >> that over the current scheme. And I do see considerable disadvantage. > > I guess, but now I'm just confused. ;) > > Cheers, > Aki > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 13:20:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEBR-0001N4-4T; Thu, 10 Aug 2006 13:19:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEBP-0001Mt-5o for sip@ietf.org; Thu, 10 Aug 2006 13:18:59 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBEBL-0005yO-Jg for sip@ietf.org; Thu, 10 Aug 2006 13:18:59 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Aug 2006 13:18:55 -0400 X-IronPort-AV: i="4.08,111,1154923200"; d="scan'208"; a="96077494:sNHT26419164" 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.20060308/8.12.11) with ESMTP id k7AHItbU028692; Thu, 10 Aug 2006 13:18:55 -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.12.10/8.12.6) with ESMTP id k7AHIte2007194; Thu, 10 Aug 2006 13:18:55 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 13:18:55 -0400 Received: from [161.44.55.154] ([161.44.55.154]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 13:18:54 -0400 Message-ID: <44DB6A7E.6080002@cisco.com> Date: Thu, 10 Aug 2006 13:18:54 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <50B1CBA96870A34799A506B2313F26670998BF40@ntht201e.siemenscomms.co.uk> <1155226095.7999.147.camel@macbuster.research.nokia.com> In-Reply-To: <1155226095.7999.147.camel@macbuster.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 17:18:54.0575 (UTC) FILETIME=[0E814FF0:01C6BCA1] DKIM-Signature: a=rsa-sha1; q=dns; l=2424; t=1155230335; x=1156094335; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Question=20regarding=20instance=20ID=20in=20GRUU=20and=2 0outbound |To:Aki=20Niemi=20; X=v=3Dcisco.com=3B=20h=3DW1oZffcBbE4wp5P7F4LQfSRhG6E=3D; b=A3BuCaRX6nj0vZmbC8JHny5eSRbN5HwA1TZ3FTfqGZQfy2ceNQZLeJG7O0G+zNv1CC7Y0tgN 89gQ24eJ5+VWEoDr5CmKfX09H8ZMShNX4kGGc5gaY9RrrADyyLwGq5qZ; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sip , "ext Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki, Another point to make. I think your model is that, because the UA has a perpetual instance ID, it is also the one that generates it. THis need not be the case. I view the instance ID a lot like the kinds of device identifiers we see in the mobile world. When a provider orders a batch of phones, they each come with a unique instance ID burned into firmware at the factory. Those get read into a database and when the phones are given to a customer, you can establish a link between the instance ID and the subscriber if you want. Consequently, when the REGISTER shows up, this is not some random instance ID that would never have been seen. It would have been known by the provider well ahead of time. Of course, the GRUU model also allows for cases where the phone does in fact djinn up its own instance ID, for softphones in particular this will be a requirement. Another unrelated point - though you don't necessarily need the persistence of the instance ID for sip-outbound, I much prefer the model where we define this concept of a UA instance identifier, and then reuse that in various places where that property comes in handy. That is better than defining similar types of identifiers in each and every other protocol that needs something roughly the same. Thanks, Jonathan R. Aki Niemi wrote: > to, 2006-08-10 kello 08:09 +0100, ext Elwell, John kirjoitti: > >>Furthermore, a UA that is in the habit of registering in more than one >>domain (in support of mobility, hot-desking, or whatever) would need to >>remember multiple cookies - gets complicated. > > > No more complicated than storing user credentials per AoR (and yes, all > of the UAs I've ever used -- black, soft, hard, mobile, or otherwise -- > do this already. > > Plus (I assume you're talking about sip-outbound) I consider the > persistent storage of the flow identifier as only a recommended courtesy > in helping the registrar invalidate flows that would otherwise be left > dangling because of a UA reboot. > > Cheers, > Aki > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 14:08:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEvt-0003Il-HS; Thu, 10 Aug 2006 14:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEvs-0003Ig-6Q for sip@ietf.org; Thu, 10 Aug 2006 14:07:00 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBEvq-0001Z3-Si for sip@ietf.org; Thu, 10 Aug 2006 14:07:00 -0400 Received: from [206.176.144.213] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7AI98e0004578 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 10 Aug 2006 13:09:09 -0500 In-Reply-To: <1155216398.7999.58.camel@macbuster.research.nokia.com> References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44DA550E.9020602@cisco.com> <1155216398.7999.58.camel@macbuster.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B49F320-181F-4560-939C-A9822000E89E@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound Date: Thu, 10 Aug 2006 13:06:54 -0500 To: Aki Niemi X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 10, 2006, at 8:26 AM, Aki Niemi wrote: > > The problem I have is letting the UA create identifiers that the > registrar uses in its internal state lookup. Now there isn't anything > totally broken with this approach per se, but it just seems like a bad > idea. > Let's pursue this a bit. Assume a hostile (or simply defective) UA that does something stupid like increment its instance-ID on each registration. As I understand it, this would generate a new GRUU for each registration. Does this consume additional resources on the registrar? Does the registrar have to keep a record of each GRUU forever in case some request comes in for that GRUU? Is there a recovery cycle for GRUUs, like garbage collection? Or does this error simply result in any messages to the "old" GRUU being lost or misrouted, and thereby hurt nobody but the user of the misbehaving UA? Are there things like buffer-overrun attacks that we might think about? Could I construct a "very long instance-ID" such that some internal buffer in the registrar is overrun? Certainly not without a programming error in the registrar, but such errors do happen. Is there any more probability of this happening in instance-ID as opposed to any other part of SIP? Maybe there is. After all, the instance-ID feeds into the GRUU calculation, and the resulting GRUU gets written to some sort of database (which may be in-memory). Is this really a substantially greater risk than any other buffer-overrun attack? What constitutes a too-long instance-ID and how do we reject it if we see one? I will note here that people probe my web servers with long-URLs a couple of times a day, especially when they find a CGI script's entry point. -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 14:53:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBFdF-0001fd-I5; Thu, 10 Aug 2006 14:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBFdE-0001fY-3Q for sip@ietf.org; Thu, 10 Aug 2006 14:51:48 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBFdB-0005kJ-NW for sip@ietf.org; Thu, 10 Aug 2006 14:51:48 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 10 Aug 2006 11:51:45 -0700 X-IronPort-AV: i="4.08,111,1154934000"; d="scan'208"; a="1846003902:sNHT26900968" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7AIpjPT003865; Thu, 10 Aug 2006 11:51:45 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7AIpguH017757; Thu, 10 Aug 2006 11:51:44 -0700 (PDT) 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); Thu, 10 Aug 2006 14:51:37 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 14:51:37 -0400 Message-ID: <44DB8038.5080903@cisco.com> Date: Thu, 10 Aug 2006 14:51:36 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44DA550E.9020602@cisco.com> <1155216398.7999.58.camel@macbuster.research.nokia.com> <6B49F320-181F-4560-939C-A9822000E89E@softarmor.com> In-Reply-To: <6B49F320-181F-4560-939C-A9822000E89E@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 18:51:37.0086 (UTC) FILETIME=[020521E0:01C6BCAE] DKIM-Signature: a=rsa-sha1; q=dns; l=2839; t=1155235905; x=1156099905; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Question=20regarding=20instance=20ID=20in=20GRUU=20and=2 0outbound; X=v=3Dcisco.com=3B=20h=3DOa/VNwPzdLqO79eqZZ6+DMJpgWI=3D; b=sS6MrUH5M7NFkp8BnPTa57P4hqr2Je5WtCNbAg3vTOky0FCOIoVUyG8s6te1+i0hIV7gQvJJ t1cdWr6DhKKACbIEgS8Z59+3ds6DbhdcSXIw+3Fp9/dPcXFZYogmLQS0; Authentication-Results: sj-dkim-6.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: sip , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Aug 10, 2006, at 8:26 AM, Aki Niemi wrote: > >> >> The problem I have is letting the UA create identifiers that the >> registrar uses in its internal state lookup. Now there isn't anything >> totally broken with this approach per se, but it just seems like a bad >> idea. >> > > Let's pursue this a bit. > > Assume a hostile (or simply defective) UA that does something stupid > like increment its instance-ID on each registration. > > As I understand it, this would generate a new GRUU for each registration. > > Does this consume additional resources on the registrar? Does the > registrar have to keep a record of each GRUU forever in case some > request comes in for that GRUU? Is there a recovery cycle for GRUUs, > like garbage collection? > > Or does this error simply result in any messages to the "old" GRUU being > lost or misrouted, and thereby hurt nobody but the user of the > misbehaving UA? It *can* be implemented so as to behave as you describe in the last paragraph above. > Are there things like buffer-overrun attacks that we might think about? > > Could I construct a "very long instance-ID" such that some internal > buffer in the registrar is overrun? > > Certainly not without a programming error in the registrar, but such > errors do happen. Is there any more probability of this happening in > instance-ID as opposed to any other part of SIP? I don't think so. > Maybe there is. After all, the instance-ID feeds into the GRUU > calculation, and the resulting GRUU gets written to some sort of > database (which may be in-memory). Is this really a substantially > greater risk than any other buffer-overrun attack? I think a reasonable implementation is likely not to store the gruu at all. It need not be stored to be able to resolve incoming requests addressed to it, and it can be computed on the fly in order to return in response to REGISTER requests. > What constitutes a too-long instance-ID and how do we reject it if we > see one? Depending on who you want to blame, I think either a 400 or 500 response would be appropriate. If we want to worry about this, then there are lots of other things to worry about: Branches, to/from tags, callids, (the list goes on and on). Paul > I will note here that people probe my web servers with long-URLs a > couple of times a day, especially when they find a CGI script's entry > point. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 10 16:16:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBGvc-00036i-Vl; Thu, 10 Aug 2006 16:14:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBGvb-00036d-9K for sip@ietf.org; Thu, 10 Aug 2006 16:14:51 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBGvY-0000oK-VD for sip@ietf.org; Thu, 10 Aug 2006 16:14:51 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k7AKEmcj025034; Thu, 10 Aug 2006 15:14:48 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k7AKEmd28288; Thu, 10 Aug 2006 15:14:48 -0500 (CDT) Message-ID: <44DB93B8.2050408@lucent.com> Date: Thu, 10 Aug 2006 15:14:48 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Re: [Simple] UDP - what if response is bigger than 1500 bytes (ethernet MTU)? References: <3ACC9A25264A684F82C71840111F979801EC5E54@carrera.eu.tieto.com> <44BE3426.3050502@alcatel.fr> <44BEB632.9020006@lucent.com> <1154072153.21805.13.camel@macbuster.research.nokia.com> In-Reply-To: <1154072153.21805.13.camel@macbuster.research.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki Niemi wrote: > On ke, 2006-07-19 at 17:46 -0500, ext Vijay K. Gurbani wrote: > >>This remains a problem; I have had a quick chat with Scott >>Lawrence on it and we'll be submitting a draft latter part >>of next week on one way to deal with this. > > > I'm curious, can that draft really suggest anything other than simply > "MUST NOT use UDP"? Aki: Alas, no. Maybe when we get SIP/3.0, then we can get rid of UDP, forking, retargetting, and sips ;-) But seriously, the reasons that Willis et al. list in Section 3 of their work [1] long time ago about the applicability of UDP are still pertinent. About the best we may be able to do is to provide a repairable 4xx response. That is what the draft suggests. The edit token is with my co-author, Scott Lawrence. As soon as he's done, we will submit the draft. [1] D. Willis and B. Campbell, "Session Initiation Protocol Extension to Assure Congestion Safety," IETF Internet-Draft, Work in Progress, October 2003. Archived at: http://tools.ietf.org/wg/sip/draft-ietf-sip-congestsafe/ draft-ietf-sip-congestsafe-02.txt Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 17:06:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBHiE-0005zk-2g; Thu, 10 Aug 2006 17:05:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBHiB-0005v0-QC for sip@ietf.org; Thu, 10 Aug 2006 17:05:03 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBHiA-0001RS-CH for sip@ietf.org; Thu, 10 Aug 2006 17:05:03 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7AL50cX030561; Fri, 11 Aug 2006 00:05:01 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 00:04:12 +0300 Received: from essapo-nirac25361.europe.nokia.com ([10.162.253.61]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 11 Aug 2006 00:04:12 +0300 Subject: Re: [Sip] Re: [Simple] UDP - what if response is bigger than 1500 bytes (ethernet MTU)? From: Aki Niemi To: "ext Vijay K. Gurbani" In-Reply-To: <44DB93B8.2050408@lucent.com> References: <3ACC9A25264A684F82C71840111F979801EC5E54@carrera.eu.tieto.com> <44BE3426.3050502@alcatel.fr> <44BEB632.9020006@lucent.com> <1154072153.21805.13.camel@macbuster.research.nokia.com> <44DB93B8.2050408@lucent.com> Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Fri, 11 Aug 2006 00:04:11 +0300 Message-Id: <1155243851.31632.29.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2006 21:04:12.0994 (UTC) FILETIME=[881C5A20:01C6BCC0] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org to, 2006-08-10 kello 15:14 -0500, ext Vijay K. Gurbani kirjoitti: > But seriously, the reasons that Willis et al. list in Section 3 > of their work [1] long time ago about the applicability of > UDP are still pertinent. You mean 'tiny' mobile phones and extremely high-volume proxies? Well, I think I can speak to the former, and usually such tiny phones have an even tinier battery. NAT/FW keepalives every 20 sec or so eat that tiny battery up really fast. Modern mobile phones also start to have the horsepower that PCs in the 90s had, and their networking stack is *at least* as good. :) In other words, I don't buy it. ;) As to the latter, I wonder why TCP is supposed to be so much more expensive. Is it the connection establishment overhead, or the performance penalty of juggling with too many open TCP sockets? In any case, security is completely broken in SIP over UDP, so that sort of makes all of the arguments for UDP moot anyway. > About the best we may be able to do is to provide a repairable > 4xx response. That is what the draft suggests. That could work. > The edit token is with my co-author, Scott Lawrence. As soon > as he's done, we will submit the draft. I will surely take a look. In the mean time, I guess I'll just have to wait for SIP/3.0, then. ;-) Cheers, Aki -- Aki Niemi Nokia Research Center _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 10 17:07:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBHj9-0006yB-Bs; Thu, 10 Aug 2006 17:06:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBHj7-0006y6-Gk for sip@ietf.org; Thu, 10 Aug 2006 17:06:01 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBHj5-0001ZN-Tn for sip@ietf.org; Thu, 10 Aug 2006 17:06:01 -0400 Received: by py-out-1112.google.com with SMTP id m51so892273pye for ; Thu, 10 Aug 2006 14:05:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fx9HCsMeUV4AbzQlzu0cC4Wb2A8PpryizcobY1mkjsB+UoXFr+DJpxjiCcF9QXvEIXOQmq1rtjtMQvtSr2+LqFB/tvkkZqloSJiqzsam5cMZ5xd9ju4rBxOC7c8HAQbR+PjM6j9qOVWoswt4R9umzMr4bcbNOk/J6chByihWcSU= Received: by 10.35.49.1 with SMTP id b1mr4538060pyk; Thu, 10 Aug 2006 14:05:59 -0700 (PDT) Received: by 10.35.79.14 with HTTP; Thu, 10 Aug 2006 14:05:59 -0700 (PDT) Message-ID: <953beacc0608101405m1aa4ce81p86e6bc4f5ad98b46@mail.gmail.com> Date: Thu, 10 Aug 2006 14:05:59 -0700 From: "Rohan Mahy" To: "Aki Niemi" Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound In-Reply-To: <6B49F320-181F-4560-939C-A9822000E89E@softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44DA550E.9020602@cisco.com> <1155216398.7999.58.camel@macbuster.research.nokia.com> <6B49F320-181F-4560-939C-A9822000E89E@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki, Taking some of Dean's questions and running with them, I think there are three kinds of implementations with respect to setting the instance-id: 1) malicious 2) stupid 3) correct Examining the implications of the UA setting the instance-id in each of these cases: 1) It makes no difference who generates the "cookie". A malicious UA will probe all the available nooks and crannies. 2) A stupid UA can either change its instance-id when it isn't supposed to (in which case it is only hurting itself), or it and another stupid UA can choose the same instance-id and AOR, in which case only one of the two UAs will work at a time. They will effectively "duel". I expect this would be pretty easy to detect from the symptoms alone. I consider this a very minor problem. 3) For correctly implemented UAs, each category of UA generates a UUID once according to some relavent algorithm. This UUID is the same for each target server, for each AOR, etc.. It is easy to store and once the programmer figures out which algorithm to use, easy to generate. thanks, -rohan On 8/10/06, Dean Willis wrote: > > On Aug 10, 2006, at 8:26 AM, Aki Niemi wrote: > > > > > The problem I have is letting the UA create identifiers that the > > registrar uses in its internal state lookup. Now there isn't anything > > totally broken with this approach per se, but it just seems like a bad > > idea. > > > > Let's pursue this a bit. > > Assume a hostile (or simply defective) UA that does something stupid > like increment its instance-ID on each registration. > > As I understand it, this would generate a new GRUU for each > registration. > > Does this consume additional resources on the registrar? Does the > registrar have to keep a record of each GRUU forever in case some > request comes in for that GRUU? Is there a recovery cycle for GRUUs, > like garbage collection? > > Or does this error simply result in any messages to the "old" GRUU > being lost or misrouted, and thereby hurt nobody but the user of the > misbehaving UA? > > > Are there things like buffer-overrun attacks that we might think about? > > Could I construct a "very long instance-ID" such that some internal > buffer in the registrar is overrun? > > Certainly not without a programming error in the registrar, but such > errors do happen. Is there any more probability of this happening in > instance-ID as opposed to any other part of SIP? > > Maybe there is. After all, the instance-ID feeds into the GRUU > calculation, and the resulting GRUU gets written to some sort of > database (which may be in-memory). Is this really a substantially > greater risk than any other buffer-overrun attack? > > What constitutes a too-long instance-ID and how do we reject it if we > see one? > > I will note here that people probe my web servers with long-URLs a > couple of times a day, especially when they find a CGI script's entry > point. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 11 02:17:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBQIl-0005yr-Pk; Fri, 11 Aug 2006 02:15:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBQIk-0005ym-KL for sip@ietf.org; Fri, 11 Aug 2006 02:15:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBQIk-0006ve-HM for sip@ietf.org; Fri, 11 Aug 2006 02:15:22 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBQIi-0007xq-Gd for sip@ietf.org; Fri, 11 Aug 2006 02:15:22 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1F3CB6E0001; Fri, 11 Aug 2006 08:15:03 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 08:15:02 +0200 Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 08: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 Subject: RE: [Sip] Question regarding instance ID in GRUU and outbound Date: Fri, 11 Aug 2006 08:15:00 +0200 Message-ID: <33D71F0FC0684C4C8A3BB76989EDED9C024BCE71@eesmdmw020.eemea.ericsson.se> In-Reply-To: <44DB403D.2090100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question regarding instance ID in GRUU and outbound Thread-Index: Aca9DXo8mdbPHrifTL2XrVuwt7fgPw== From: "Jesus Javier Arauz \(MI/EEM\)" To: "Paul Kyzivat" , "Aki Niemi" X-OriginalArrivalTime: 11 Aug 2006 06:15:02.0318 (UTC) FILETIME=[7B0AFCE0:01C6BD0D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org See inline. Regards, /Javier=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: jueves, 10 de agosto de 2006 16:19 To: Aki Niemi Cc: sip Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound Aki Niemi wrote: >> I also think its easier for a server to remember an instance ID to=20 >> GRUU binding for a long time, than it is for a client to remember its >> cookie for a long time AND for the server to remember the cookie to=20 >> GRUU mapping for a long time. GRUU persistence would depend on a=20 >> client remembering its cookie basically forever. GRUU currently=20 >> doesn't require persistent storage of any soft state in the client. >=20 > Except it has to persistently store the instance-ID. When the UA moves > to another device, it supposedly needs to take the instance ID with it? Well, that depends on whether you think it makes sense for a UA to move to another device, or whether you thing UAs on different devices are intrinsically different. I don't think there is a single answer to that - it seems to be a religious issue. Some time ago I got into a debate about this with some IMS folk, regarding how this should work on cell phones. I though the instance id ought to move around with the ISIM. Some others had very strong opinions that the instance id should be tied to some id (I forget which one) that is tied to the body of the cell phone rather than the ISIM. I gave up on that argument. It can be an individual choice by the maker of the device and the software that runs on it. [Javier] The "id" you refer to above is the IMEI, which is sort of a "serial number" that is assigned to each cell phone sold around the globe. Generating the instance ID of a cell phone from its IMEI value makes a lot of sense. The ISIM holds user-related information only, thus that information alone cannot be used to generate an instance ID that refers to the device where the ISIM is running. That is orthogonal to whether the instance ID must change when a user moves his ISIM around. The whole point of GRUU is to be able to reach a specific user at a specific device, in most cases because it is known that user is answering on that device. Hence if the user moves around his ISIM the instance ID must change and he will get a new GRUU from the registrar. In any case, it should often be the case that the instance id can be derived from some piece of unchanging state that the UA has access to.=20 In such cases there is no need for the UA to take extra actions to save it. There are cases when this isn't the true. The most obvious one to me is when a soft phone is installed on a PC. There can be multiple softphones potentially running concurrently on the same PC, but operating and registering independently of one another. In such a case each one must come up with a unique instance id. It may even be the case that the same softphone installation can be used by different users on the PC, each with a unique identity. In these cases there may be a need to explicitly persist the instance id in a store that properly correlated with the particular notion of "instance" that makes sense under the circumstances. [Javier] IMHO the cases you mention are not a problem. In the first case, since each softphone's UAS will be bound to its own TCP/UDP port each softphone might receive different, unique GRUUs if the registrar includes that port in the generated GRUU. In the second case, since each user has his own AoR the GRUUs generated will be unique for each user if the registrar includes the AoR in the GRUU. A more complex situation arises when the same AoR is registered by different users through the same shared softphone. In that case the softphone must set the "grid" parameter to some value unique for each user (it could be e.g. the user's login name or based on the user's login password). > There's really no difference here to the (implicit) requirement on a=20 > UA that the UA has to store the user credentials, per AOR, in=20 > persistent storage, forever. >=20 [Javier] The UA does not need to store any user-related information, nor does it need to use different information per AoR. It only needs a bit of information it knows is unique and unchanging for the device the UA is running on. The uniqueness characteristic might seem controversial (i.e. how can it be guaranteed that some device manufactured next year is not going to produce instance Ids that collide with IMEI or MAC address values?) but if the URN concept is used properly there should not be any collision. > Unless a blackphone intends to query a digest password upon every=20 > registration after a reboot cycle? That probably wouldn't work,=20 > especially with a numeric keypad and an alphanumeric password. Or at=20 > least I would toss that phone out the window pretty quickly. ;) The black phone can simply derive the instance id from its serial number or some other convenient and unchanging piece of info. Paul _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 03:36:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBRXp-0005o8-Ft; Fri, 11 Aug 2006 03:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBRXn-0005o3-Sd for sip@ietf.org; Fri, 11 Aug 2006 03:34:59 -0400 Received: from jes-fe2.zx.nl ([194.187.76.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBRXm-0005nD-K0 for sip@ietf.org; Fri, 11 Aug 2006 03:34:59 -0400 Received: from Inbox ([84.241.204.100]) by jes-fe2.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J3T00GF4S1A7680@jes-fe2.zx.nl> for sip@ietf.org; Fri, 11 Aug 2006 09:39:24 +0100 (WEST) Date: Fri, 11 Aug 2006 09:35:03 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] Outbound Issues: slides 3 and 4 To: Hisham Khartabil , Hadriel Kaplan Message-id: <0J3T00GF5S1C7680@jes-fe2.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sip@ietf.org, 'Rohan Mahy' , 'Fredrik Thulin' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok, so lets standardise a mechanism for servers to explicitly indicate=20 that it supports the following, even if configured in the client: - STUN - loose-routing - comp=3Dsigcomp - ... [jvb] Yes, I proposed this too some time ago. "Proxy capabilities" similar = to callee capabilities; I was thinking about parameters in Record-Route, Se= rvice-Route and Path headers. To start with,";extensions=3D..." would help Regards, Jeroen= _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 03:55:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBRqM-0003A1-CZ; Fri, 11 Aug 2006 03:54:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBRqK-000398-S9 for sip@ietf.org; Fri, 11 Aug 2006 03:54:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBRqJ-0007MU-6M for sip@ietf.org; Fri, 11 Aug 2006 03:54:08 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6896D8E0001; Fri, 11 Aug 2006 09:54:06 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 09:54:06 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 09:54:05 +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 Subject: Indicating proxy capabilities (was: RE: [Sip] Outbound Issues: slides 3 and 4) Date: Fri, 11 Aug 2006 09:54:04 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1320@esealmw113.eemea.ericsson.se> In-Reply-To: <0J3T00GF5S1C7680@jes-fe2.zx.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Indicating proxy capabilities (was: RE: [Sip] Outbound Issues: slides 3 and 4) Thread-Index: Aca9GLgnAsAT5ENBRcapPHKwru/qXwAADjPg From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen Van Bemmel" , "Hisham Khartabil" , "Hadriel Kaplan" X-OriginalArrivalTime: 11 Aug 2006 07:54:05.0481 (UTC) FILETIME=[5171B190:01C6BD1B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip@ietf.org, Rohan Mahy , Fredrik Thulin , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, I changed the name of the topic. It's a generic issue, and not related to outbound and STUN keep-alive only. >>Ok, so lets standardise a mechanism for servers to explicitly indicate that it supports the following, even if=20 >>configured in the client: >> >>- STUN >>- loose-routing >>- comp=3Dsigcomp >>- ... > >[jvb] Yes, I proposed this too some time ago. "Proxy capabilities" similar to callee capabilities; I was thinking about=20 >parameters in Record-Route, Service-Route and Path headers. To start with,";extensions=3D..." would help [CHH] I also think it is something we should look into - especially when we are now have functions and extensions which require proxy support of certain functions (until now most extensions have been end-to-end, without any specific proxy support). Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 04:51:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBSi4-0002hn-Jr; Fri, 11 Aug 2006 04:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBSi2-0002hi-OZ for sip@ietf.org; Fri, 11 Aug 2006 04:49:38 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBShz-0001Mq-RM for sip@ietf.org; Fri, 11 Aug 2006 04:49:38 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7B8nP8t006341; Fri, 11 Aug 2006 11:49:27 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 11:48:30 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 11:48:29 +0300 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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 11:48:29 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F029A5AFF@esebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca6+HUzhNHqEgQeSE+uIj/XNXae4QCKen9A From: To: , X-OriginalArrivalTime: 11 Aug 2006 08:48:29.0701 (UTC) FILETIME=[EB122350:01C6BD22] X-Spam-Score: 0.2 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi,=20 >We had a very long discussion in Montreal about discovery and=20 >validation of a SIP outbound proxy server's ability to receive STUN=20 >requests. While the vast majority of the room was comfortable that=20 >"keepalive=3Dstun" in a URI was a sufficient indicator that an outbound = >proxy supports SIP and STUN over the same port, a small but extremely=20 >vocal minority had significant problems with this assumption. > Concern that the mailing list combatants on these issues are not=20 > present in the room; this will have to go to the mailing list. Being one of those "extremely vocal combatants not present in Montreal" it is now time for myself to express my opinion about proposed solutions and the related discussions I could recap from the IETF SIP WG meeting minutes and the emails on this subject prior to and after the meeting. First of all I was very delighted to see that one of the authors of SIP Outbound finally took this issue up and proposed a solution for it, to be added to the Outbound draft: >I am willing to try a validation proposal which=20 >adds no extra round trips if the SIP UA was indeed correctly=20 >configured. > >The specific proposal works like this. A UAC which has an=20 >outbound URI indicating with ;keepalive=3Dstun that the next=20 >hop can support STUN messages on the SIP port, needs to verify=20 >the first hop supports STUN before sending any STUN messages.=20 >The UAC sends its first SIP message to the next hop with a=20 Proxy-Require: sip-stun. If the URI was correct=20 >(STUN was supported), and the first-hop is an intermediary, the=20 >first-hop removes the Proxy-Require and forwards the SIP request=20 >(probably a REGISTER request) along adding no additional delay. A=20 >positive response to a REGISTER or OPTIONS with Supported:=20 >outbound and no error counts as positive confirmation that either=20 >the registrar supports STUN or expects to never receive a request=20 >without getting it from an outbound proxy which did not complain=20 >about the Proxy-Require [1]. If the UAC was misconfigured=20 >(the first-hop intermediary does not support STUN keepalives), >either the first hop will reject the SIP request (if it is an=20 >intermediary), or the registrar will not include=20 >an indicator that it supports outbound (if the first hop was the=20 >registrar). I find this solution perfect: it is simple, complete, lightweight,=20 proven to work in other contexts, it solves the problem neatly.=20 I would say: "Just do it and let the Outbound draft converge". But it seems to be not that easy after all. Let me recap the current situation with this proposal. >From the raw WG notes and emails about the subject after the=20 meeting I was able to gather the following summary for this proposal. Please tell if I have misinterpreted your statement=20 in the mailing list and counted you into a wrong camp: A. GO: 10 WG members have expressed that they understand the=20 Proxy-Require solution and do not see a problem with it: Rohan Mahy Robert Sparks Hadriel Kaplan Jeroen van Bemmel Bob Penfield Christer Holmberg Francois Audet Joel M. Halpern Dean Willis Erkki Koivusalo B. No-GO 4 WG members are opposing the Proxy-Require solution Cullen Jennings Jonathan Rosenberg Hisham Khartabil Fredrik Thulin I would like to revisit the issues explicitely mentioned in the mailing list against the Proxy-Require solution=20 and my conclusions for each of those issues. Sorry that this becomes long story, but I just could not help it: 1. Is there a real problem to be solved ? Cullen Jennings >Just so we are clear on the when this could be a problem.... > >For any UA that is automatically configured, this is unlikely to =20 >every be a problem. What we are talking about here is UA where some =20 >human types in the configuration information to the UA. Even though =20 >they were told to enter example.com as the outbound proxy, they =20 >decide to enter example.com;keep-alice=3Dstun because perhaps they saw = >in some other system. Please note that user possibly does not need to type the ;keep-alive=3Dstun. The UA might have a user interface with one button with text "Is the phone behind a NAT ?" and after selecting "Yes" the phone would add this URI parameter. Perhaps badly designed UA, but possible. Christer Holmberg: >Assuming the UA is configured with a URI, yes. But, in case the=20 >UA only gets the IP address of the proxy, you still have a problem. Jonathan Rosenberg: >1. a user types in their outbound proxy and adds keepalive=3Dstun when=20 >they shouldn't have >2. outbound proxy is discovered via DHCP, and since DHCP provides a=20 >hostname and not a URI, a UA constructs a URI, and since it supports the=20 >stun keepalive adds the parameter > >Case #2 is a legitimate cause for concern.=20 Conclusion: it is a problem because of the following reasons: - UA might only have the IP address of the proxy available - UA might get the domain name from DHCP without URI params - UA might be configured by the user incorrectly 2. Is the solution in scope of SIP Outbound draft ? Cullen Jennings: >I think this is out of scope of this draft. Jonathan Rosenberg: > I agree its out of scope.=20 > >However if we had a mechanism=20 >for autodiscovery of outbound proxies, where a URI was provided by that >proxy itself, then this use case goes away, and the need for some of=20 >these verification mechanisms goes away too. > >So, I had proposed at the mike during ietf a mechanism for discovery=20 >using Service-Route (Path is the wrong direction), which would make sure=20 >that, even if a client discovers the proxy initially via DHCP, it=20 >quickly learns a URI from that proxy which would inform it about whether=20 >stun is supported. Draft coming soon on this... > >If we had such a mechanism, then I dont think we need any of this mess. >Since we need a proper discovery mechanism regardless lets solve that=20 >problem and ditch the extra mechanism. Christer Holmberg: >Anyway, if you DO agree that it's relevant we don't need=20 >to argue whether it's in the scope or not :) Dean Willis: > There have been several options mentioned to do this, a simple=20 > way is to have the edge proxy insert a flag. Question is: why not? > >I find that I've developed a great deal of sympathy for the above=20 >position. Discovery is indeed separable from error-detection (or=20 >confirmation, detecting "absence of error"). Conclusion: - Since this draft creates such a problem it is in my=20 understanding in the scope of this draft to fix it, expecially when the means are already outlined and seem to be well understood and widely accepted. - Moving the solution to another draft would mean that we introduce the problem to the market when the draft is approved as RFC but would postpone solving it to=20 some undetermined date (if ever). 3. Does Proxy-Require technique work or is it too complex ?=20 Jonathan Rosenberg: >In particular, though I dont really see a lot of harm in Rohans=20 >Proxy-Require proposal, I think its unnecessary complexity if=20 >you have a proper discovery mechanim.=20 Is the proposal really so complex at all ? I propose the following text for the Outbound draft: The UA SHOULD add a Proxy-Require header field with the=20 value "sip-stun" to its REGISTER request. When the UA receives 200 OK with Supported: Outbound it can be sure that the next hop will support STUN keepalives. The proxy MUST remove the "sip-stun" value from the=20 Proxy-Require header field and then remove the header=20 if no values remain before forwarding the request to the next hop. If you have any doubts whether it works or not, please look into RFC 3329 from which I copied this text and=20 modified it to sip-stun purpose. It is proven and widely=20 deployed technique within Sec-Agree. Dean Willis: >The only thing I have seen in Rohan's proposal that makes people=20 >queazy is the handling of the proxy-require -- that is, removing=20 >it in the first hop proxy. > >To quote a few IETF's back, "That doesn't bother me at all". > >But it seems to bother Cullen and a few others, even if I did=20 >borrow his words to say I'm ok with it. Conclusion: - As Proxy-Require is used in a similar way in RFC 3329 with wide deployment this concern can be ignored. 4. Can UA rely on the response from the proxy ? Fredrik Thulin >The argument that a response containing something saying=20 >"I claim I can handle STUN requests you send me" is to be=20 >trusted, but configuration saying ";keepalive=3Dstun" is not=20 >is flawed.=20 Hadriel Kaplan >I would argue fairly vehemently that a server explicitly >indicating it supports something is far more reliable=20 >than a UA believing the server supports something based=20 >on a local config setting. Conclusion: - As this is hardcoded information in the proxy implementation, it is very probably reliable - It works in a similar way for Sec-Agree too 5. What if there is no proxy between UA and registrar ? Rohan Mahy: >>Francois: Are you worried that such a REGISTRAR may not believe=20 >>the Proxy-Require was intended for itself? > >Exactly. Proxy-Require is generally supposed to be ignored by UAs. Conclusion: - Not a problem since in this situation the UA can infer from Supported: Outbound header of 200 OK that the registrar also supports STUN keepalives. Just like outlined in Rohan's proposal. 6. Mandating UA not to send STUN packets before it has sent a REGISTER with Proxy-Require towards the proxy ? Hisham Khartabil: >I don't like this proposal. I'm still with the camp that says: if=20 >configured, then it must be true. > >My main objection is that in this proposal, you are required to send=20 >SIP messages before STUN messages. That's a mandate that I'm not=20 >comfortable with since I might want to send STUN first to discover my=20 >public IP/port to populate the contact header before I send the first=20 >REGISTER. Jonathan Rosenberg: >Hisham - why would you want to do this? The whole idea of sip-outbound=20 >is to make the IP in the Contact irrelevant. It will be ignored anyway. >Perhaps you are worried about an outbound proxy that supports stun but a=20 >registrar that doesn't support sip-outbound? > >There are some pretty sizeable security risks in doing this. Conclusion: - Jonathan already rejected the idea Hisham had - On the other hand it is possible to specify that the UA either SHOULD or MAY add Proxy-Require, instead of mandating it, if this is still regarded as a problem 7. Is there any better solution available so that=20 Proxy-Require would not be needed ? 7.1 Sending OPTIONS before REGISTER Cullen Jennings: >How about if we said something like > >If the UA did not learn the outbound proxy set thru auto-config or =20 >discovery mechanisms, then it MUST do an OPTIONS message first and =20 >check for a sip-stun option tag. (clearly more wording needed but you =20 >know what I mean) > >Would that work for you? I suspect it would work for most people. I'd =20 >certainly be in favor of that.=20 Cullen Jennings >For these reasons, I don't think this whole problem is not a huge =20 >deal. However, if people do think it is a big deal, the obvious =20 >solution to it is send and OPTIONS message to find out if the server =20 >supports this. Most people don't seem to think this is enough of a =20 >problem to warrant and additional RTT when a UA boots. We can come up =20 >with other possible solutions to this too (as there are at least =20 >three others on this same thread). Conclusion: - Sending OPTION has the drawback of extra RTT - Further on in my understanding it is more complex solution for both the UA and the proxy (more logic to be implemented to both ends) compared to Proxy-Require solution - I am not in favour of OPTION for those reasons 7.2 Sending STUN packets and waiting for responses Dean Willis: >Cullen suggested an alternate possibility that might work. > >I'll try and paraphrase: > >A UAC which has an outbound URI indicating with ;keepalive=3Dstun that = >the next hop can support STUN messages on the SIP port needs to =20 >verify the first hop supports STUN before repeatedly sending STUN =20 >messages. The UAC may initially try sending STUN messages to the SIP =20 >port of the first hop node. If the UAC does not receive a correct =20 >STUN response (within some timer?) then it must assume that this =20 >mode does not support STUN, and proceed without using STUN until it =20 >has some evidence that the first-hop node might have changed, in =20 >which case it retries the STUN requests as per the initial attempt. Hadriel Kaplan: > > (3) checking a server supports a malformed message by actually > > sending the malformed message is, well, simply rude. :) =20 > > It makes this draft a new torture test; > but what IETF RFC would actually mandate you to send SIP to your IMAP > server, to see if the IMAP server also understands SIP? A mis-configuration > or user error is a very different context, I think. For example, in one you > blame the operator of the DNS, and in the other you blame the IETF. =20 Conclusion: - I am in an agreement with Hadriel on this. Getting an explicit information by a query is much cleaner solution than rather guessing the result from sending an arbitary number of STUN packets and checking if any responses are received. It is probably obvious that I am not convinced by any of the raised issues that the proposed Proxy-Require technique would not work or that it could not easily be added into SIP Outbound draft. So I am clearly in favour of it. Whether or not the UA is mandated to add Proxy-Require header to REGISTER does not matter so much to me but I would hope to be able to design=20 UAs that have such a possibility. Regards, Erkki =20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 06:14:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBU0V-0005Ft-PM; Fri, 11 Aug 2006 06:12:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBU0U-00059y-79 for sip@ietf.org; Fri, 11 Aug 2006 06:12:46 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBU0S-00056P-Q8 for sip@ietf.org; Fri, 11 Aug 2006 06:12:46 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 5E4423C056; Fri, 11 Aug 2006 12:12:41 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10056-01-53; Fri, 11 Aug 2006 12:12:41 +0200 (CEST) Received: from [192.168.123.15] (c-affae055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.250.175]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id C6CB73BEF5; Fri, 11 Aug 2006 12:12:40 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 12:11:29 +0200 User-Agent: KMail/1.9.3 References: <8B1D53AEF7B03449A6D3771B3B7F850F029A5AFF@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F029A5AFF@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608111211.29581.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.549 tagged_above=-99 required=7 tests=[AWL=0.116, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Friday 11 August 2006 10:48, Erkki.Koivusalo@nokia.com wrote: ... > 4. Can UA rely on the response from the proxy ? > > Fredrik Thulin > > >The argument that a response containing something saying > >"I claim I can handle STUN requests you send me" is to be > >trusted, but configuration saying ";keepalive=stun" is not > >is flawed. > > Hadriel Kaplan > > >I would argue fairly vehemently that a server explicitly > >indicating it supports something is far more reliable > >than a UA believing the server supports something based > >on a local config setting. > > Conclusion: > - As this is hardcoded information in the proxy > implementation, it is very probably reliable > - It works in a similar way for Sec-Agree too I feel kind of misinterpreted here. My point was that no matter how strong of an indication the UA receives that the first-hop proxy supports STUN-in-SIP, it must still _verify_ that it does, and stop sending STUN requests if the proxy in fact doesn't, even if it claims it does. The proxy explicitly saying it supports STUN-in-SIP (through the Proxy-Require scheme, or some other) is doubtlessly a strong indicator but it doesn't _prove_ that the proxy supports STUN-in-SIP. This leads me to my opinion that just about any indicator at all the UAC has that the first-hop proxy supports STUN-in-SIP is a good enough reason for the UAC to try and see if it actually does. I don't care what the indicator looks like, but I don't want the Outbound draft to be tied up in what I consider pointless discussions, and complex solutions. I agree with those that wants to have _some_ kind of indicator of support, but I think most people are overstating the importance of not sending a few STUN-in-SIP packet to a proxy that doesn't support it. Local configuration in the UAC is a good enough indicator for me. I believe the blacklist argument to be FUD. /Fredrik _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 07:34:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBVFP-00042s-R2; Fri, 11 Aug 2006 07:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8m8B-0007ov-8w for sip@ietf.org; Thu, 03 Aug 2006 18:57:31 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8m84-0002bo-KY for sip@ietf.org; Thu, 03 Aug 2006 18:57:31 -0400 Received: from [192.168.2.104] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k73MxKDM008459 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Aug 2006 17:59:21 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: IETF SIP List Message-Id: From: Dean Willis Date: Thu, 3 Aug 2006 17:57:11 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.2 (/) X-Scan-Signature: 9702376857f862f23e9cb0252afaa141 X-Mailman-Approved-At: Fri, 11 Aug 2006 07:32:14 -0400 Cc: Cullen Jennings , Keith Drage Subject: [Sip] Draft minutes for IETF 66 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0480607744==" Errors-To: sip-bounces@ietf.org --===============0480607744== Content-Type: multipart/alternative; boundary=Apple-Mail-4-244972171 --Apple-Mail-4-244972171 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Ok, folks. Here's the first pass at the minutes for IETF 66. Please =20 excuse the HTML, but it seems to be fashionable for the proceedings. They're also webbed at: http://www.softarmor.com/sipwg/meets/ietf66/notes/minutes-sip-=20 ietf66.html Please respond with any corrections on the list. Session Initiation Protocol (SIP) WG Minutes edited by Keith Drage, with Security Breakout edited by Dean =20 Willis Based on notes by Bruce Lowekamp, Dale Worley, Ben Campbell, A.C. =20 Mahendran and Spencer Dawkins. Meeting chaired by Dean Willis and Keith Drage. Slides presented included in the proceedings. SIP session 1 Agenda bash and current status The note well statement was displayed Slides: SIP-1.pdf Note takers were identified. Thanks to Bruce Lowekamp, Dale Worley =20 and Spencer Dawkins for taking notes for session 1. It was identified that there was expected to be an ad-hoc SIP session =20= on the security issues that were being found with RFC 3261, in regard =20= toSIPS usage. The agenda was agreed with the insertion of a quick slide from =20 Gonzalo Camarillo on SIGCOMP activities. The following SIP RFCs were identified to have been published since =20 IETF#65: RFC 4458: Session Initiation Protocol (SIP) URIs for Applications =20 such as Voicemail and Interactive Voice Response (IVR) =96 AD sponsored =20= informational RFC 4483: A Mechanism for Content Indirection in Session Initiation =20 Protocol (SIP) Messages =96 Proposed standard RFC 4485: Guidelines for Authors of Extensions to the Session =20 Initiation Protocol (SIP) =96 Informational RFC 4488: Suppression of Session Initiation Protocol (SIP) REFER =20 Method Implicit Subscription =96 Proposed standard RFC 4508: Conveying Feature Tags with the Session Initiation Protocol =20= (SIP) REFER Method =96 Proposed standard RFC 4538: Request Authorization through Dialog Identification in the =20 Session Initiation Protocol (SIP) =96 Proposed standard The following SIP internet-draft was currently in AUTH48: draft-ietf-sip-identity-06 The following SIP internet-draft was currently in RFC editor's queue: draft-ietf-simple-event-list-07 (although this was developed in =20 SIMPLE it was submitted to IESG via SIP to cater for the SIP change =20 process) The following SIP internet-draft are currently with IESG draft-ietf-sip-mib-11 draft-ietf-sip-e2m-sec-02 The following SIP internet-draft is ready for IESG draft-ietf-sip-answermode-01 The following SIP internet-drafts are in working group last call draft-ietf-sip-connect-reuse-05 draft-ietf-sip-gruu-09 (REVIEWERS REQUIRED TO FINISH as only two WG =20 members identified they had fully reviewed the draft =96 this will be =20= the first document to go through the full review process identified =20 by the WG chairs to the list) draft-ietf-sip-fork-loop-fix-02 Existing milestones were identified, along with new dates for the =20 existing milestones (with the new separation of WGLC start dates and =20 IESG submission dates for each internet draft being progressed to RFC. In response to a question from the floor, this leaves 9 charter items =20= the SIPWG currently has in progress. This was targeted at identifying =20= when the SIP WG would complete its current work. At this point the WG chairs identified the new WG items that were =20 identified by the WG at IETF#65 and subsequent email activity which =20 identified dates through to the end of 2007. These were still subject =20= toapproval by the IESG as the WG chairs had only got the list to the =20 IESG secretary late the previous week. In response to another question from the floor as to whether the =20 dates could be earlier (specifically for location conveyance), the WG =20= chairs agreed that dates could always be earlier, providing the WG =20 was satisfied that the document was actually ready. However the WG =20 chairs stated that this represented their best estimate of what was =20 realistic. The WG chairs then conducted some polls concerning support for some =20 of the current work: Question regarding draft-ietf-sip-certs: Response to list poll was =20 universally positive, but offline WG chair had had some negative =20 comments. Is this leading toward implementation? Consensus: Yes, at =20 least 5 implementations are expected from the room, and no one =20 presenting objections. Question regarding draft-ietf-sip-connection-reuse. Does it still =20 provide any benefit. WG chairs identified there was a positive =20 response to the list poll. However in the meeting one WG member =20 questioned the value based on the limited number of scenarios where =20 it provides real benefit. It purported to give CPU overhead benefit, =20 which the speaker doubted. Additionally does not work through NAT and =20= requires mutual TLS to work. Is it the highest priority for the =20 minimal value it provides. A second speaker identified one advantage =20 is that it states that any entity has to reuse the existing =20 connection which is not currently stated elsewhere. Discussion =20 deferred to agenda item on the topic. Question regarding draft-ietf-sip-outbound: Should it be revised? At this point the WG chair projected a picture of a strikingly =20 flattened-looking squirrel on a flagstone patio. After the audience =20 expressed some distress, he remarked that this is a natural =20 phenomenon, the temperature at the time was 45 C and the squirrel is =20 cooling its belly on the stones. Discussion of aboreal rodents ensues =20= upon presentation of the agenda. Question regarding draft-ietf-sip-outbound: Is it ready for WGLC? =20 Consensus: There are a number of open issues that still need to be =20 resolved. SIP and SigComp (draft-ietf-rohc-sigcomp-sip-02.txt) Gonzalo Camarillo presenting. Slides: sip-3.pdf Presentation on problem with compression and record-route. When =20 receiving a request, how to identify the previous SIP hop that sent =20 the request (in order to manage the compression status)? Plea for =20 support in resolving this issue. Outbound (draft-ietf-sip-outbound) Rohan Mahy presenting. Slides: sip-5.pdf Slide 2: Currently when STUN response indicates change in mapped =20 address, UA assumes NAT rebooted and reregisters immediately. There =20 is no authentication of these STUN keepalives. UDP problem. On =20 unprotected 802.11 networks, an attacker who can see the STUN =20 request, can easily send a response with a different mapped address =20 and will usually beat the real response. This causes UA and registrar =20= (and intervening proxies) to do work. Can melt the registrar. =20 Proposal to add timer delaying re-registration if binding appears to =20 change more than seems reasonable in some period. Discussion from floor: 3489bis (draft not yet submitted) mentions issue with forged STUN =20 binding response in security considerations. Questioned as to whether =20= this is really an amplification attack? Especially compared to =20 problems with multiple responses to a single request. don't care if we reapply the existing timer mechanism but don't =20 introduce new ones. There are better attacks that can be applied. Presenter offers beer for a better attack. Reference to http://www.usenix.org/events/sec03/tech/bellardo.html Conclusion: Do not add new timer. Slide 3: Discoverting STUN support. Current text says that keepalive =20 STUN support is "configured" (using a very broad definition of =20 configure). Incompatible with current DHCP proxy discovery (but so is =20= sigcomp) due to limitation of DHCP option. Do we need another way of =20 discovering/probing for STUN support defined in this document? =20 Options: provide DHCP capability, provide DNS based option, or =20 provide some sort of probe mechanism within SIP. Discussion from floor: Suggestion of Proxy-Require, but this only allows validation, not =20 discovery. One speaker said his feedback was that something will turn this on or =20= off, not worth delaying to define something too complicated anyway. Another speaker. Jonathan was proposing STUN=3Dkeepalive, right? Really =20= like this one, because configuring in the phone is key to getting =20 deployment anyway. Consensus was considerable support for the rule that "configuration =20 information is enough to send STUN" but most would like some direct =20 validation mechanism created. Slide 4: Validating STUN support. Currently presence of =20 keepalive=3Dstun used as indicator its OK to send STUN requests. Some =20= expressed concern about misconfiguration causing proxies that don=92t =20= do STUN to get confused. More of a problem for TCP. Options: treat =20 this as a non-problem; revisit STUN keepalives over TCP problem; =20 don=92t send STUN until UA validates its OK, by including a parameter =20= in reflected Path, but Path not always present; have UA try the =20 request with a Proxy-Require: sip-stun; probe with OPTIONS. only way =20 to validate keepalive=3Dstun next issue: validating stun support. Discussion from floor: Proposal that need Proxy-Require "outbound" would solve this problem =20 rather than Proxy-Require "sip-stun". If we don't solve LR problem won't solve this. Agree with proposal any objections must explain why different than "lr" problem Concern that the mailing list combatants on these issues are not =20 present in the room; this will have to go to the mailing list. we =20 should ask for positive assents. Another speaker. Every other extension has a way to reject, this one =20 doesn't. Question put to whether document should be changed in respect of this =20= issue. No consensus. Back to validation (slide 3). More discussion: Validation concerns are about confusing next-hops with =20 misconfiguration, especially for TCP. Is this a problem? Another speaker. If you put this in the service-route, I'll be happy. validating:: third option on validating slide would render discovery =20 moot (don't send stun until validated OK through parameter in =20 reflected path) Put to meeting: is the existence of a keepalive=3Dstun in UA =20 configuration sufficient to allow transmission of stun without =20 further validation and progress document with that assumption? No =20 clear consesus with very few responses. Take to a later discussion, =20 and possibly on list. Discussion: It's the service providers, not the implementers who have a problem =20 with this. Another speaker (service provider) would prefer not to receive =20 protocol (STUN) that it doesn't support rather than have to deal with =20= it. Proposal to add words of caution and admonition, but then let =20 document o forward Query as to real problem. Identified that can cause framing problem =20 in TCP. However though that this may be self limiting. WG chairs declare there is not sufficient consensus on either of =20 these two issues (slide 3 and slide 4). Slide 5: STUN keepalive definition. Proposal that STUN keepalive =20 description is pulled into a separate section that can be implemented =20= independently. No objection from floor. Slide 6: How many flows (minimum)?: Current draft says (from Section =20 4.2): For each outbound proxy URI in the set, the UA MUST send a =20 REGISTER in the normal way using this URI as the default outbound =20 proxy. Proposed to change to SHOULD. Discussion: SHOULD must have caveat that violation can kill reliability. Fine, but can't say "does no harm" because single flow causes more =20 aggressive reregistration avalanche restart problems Consensus: Agreed to change to SHOULD - but there should be strong =20 warnings in the RFC of the dangers of not adhering to the requirement. Slide 7: Additional discovery and semantics of outbound-proxy-set. =20 Various proposals to discover or manufacture outbound-proxy-set or =20 apply different semantics. We don=92t even have all the requirements =20 written down for these proposals. Proposal: Can be addressed in =20 future extensions without any changes to outbound. No dissent from =20 floor. Slide 8: Why does registrar send to edge proxy over same connection? =20 Only needed if EP is in a foreign domain for authorization. Draft =20 defines edge proxy obliquely as in a foreign domain, and other =20 proxies as a disaggregation of a proxy/registrar. Incredibly =20 confusing. Needs to be more explicit. Request made by presenter for =20 assistance in providing text. Slide 9: How to verify edge proxy support. Currently draft says that =20 edge proxy adds a flow token to a Path header and forwards. No =20 discussion about how the registrar decides that edge proxy actually =20 did this. Proposal: edge proxy adds new parameter "ob" to Path URI to =20= indicate it added flow token appropriately. Example: Path: =20 . If no token present, registrar =20 ignores reg-id parameter, doesn=92t return Supported: outbound. Discussion: Will only be provided for first element. It is a Proxy-Require dodge. =20= Thinks OK. No time for further discussion in meeting so editor makes plea to =20 discuss offline. Slide 10: Presence of Supported: outbound. What does this mean? Today =20= it means that the registrar supports outbound. Client can use this to =20= understand that if it needs to cleanup old Contacts using RFC 3261 =20 style matching. Proposals: clarify this in the text; only include =20 Supported: outbound if any edge proxy supports outbound as well re-registering vs replacing flows: Discussion: What happens when edge proxy supports outbound but registrar does =20 not? Would the edge proxy change it's behaviour. Presenter doesn't =20 see any need to do anything differently. No objection from meeting. Slide 11: Re-registering with same reg-id. Original intent of reg-id =20 is so that UA can indicate if it wants to add a new flow or to =20 replace an existing flow. Dave Oran asked for change to language (ex: =20= SHOULD replace) to allow for a private use case. WG was later =20 uncomfortable with idea of deleting/replacing flows. In Dallas seemed =20= to have consensus to use most recent flow. Since then, many =20 complaints on the mailing list about this, and no one motivating/=20 defending previous choice. Problems with this: proxy can send traffic =20= to the wrong place (for UDP flows); no way for registrar to delete =20 state until registration expires; no way for UA to say it really =20 wants to replace flow; harder to implement on registrar; not =20 motivated by requirements. Options: leave draft as is; change back to =20= SHOULD replace flows with same reg-id; say registrar MUST replace =20 flows with same reg-id. Proposal: SHOULD replace flows. Discussion: keeping flows is very bad with amplification. Surely registrar can get rid of state at any time. new draft almost forces replacement. If two registrations are equal, =20 one must replace the other. "not a MUST, it's true by definition". SHOULD vs MUST: SHOULD: some MUST: more OBJECT TO MUST: one OBJECT TO SHOULD: more WG chair: rough consensus on MUST. Slide 12: Refresh registration on same flow. Erkki pointed out that =20 registration refresh should happen over the same flow it refreshes. =20 No issue. Slide 13: Usage of 410 response Code. Adam Roach pointed out that =20 semantics of 410 response code is inconsistent with our usage. =20 Proposal: Use 480. No issue. Outbound discovery (draft-koivusalo-sip-outbounddiscovery) Slides: sip-7.pdf Miguel Garcia presenting. Problem definition, requirements, solutions, evaluation and =20 specification - all in one small document. Discussion: proposal (not sent to list yet) - could DATA URI be used with maximum =20= number-of-flows in DNS? Concerns that we are dispersing configuration information to 17 =20 different places with no architecture supporting this. Why not put it =20= all in DNS and forget the configuration framework that's not going =20 anywhere in five years anyway? Concerns expressed about DNS approach, especially with mid-dialog =20 failure - this won't work for mid-dialog failure, no way to express =20 this in something as static as DNS. Getting k of N from a DNS starts =20 to fail with the DNS design. Proper choices can't be expressed in =20 DNS (choose one of first two and one of second two). DNS is too static. Jonathan Rosenberg will write up description of alternative approach, =20= after which the issue can be discussed. Adopt as WG draft? No decision to be made at meeting. Will take this =20 to the list to discuss. Use Case for Mid Dialog Request Routing with Outbound (draft-johns-=20 sip-outbound-middialog-draft) Slides: sip-4.pdf Sumanth Channabasappa presenting. Explores enabling failover when middle boxes fail, and its =20 interaction with the outbound flow mechanism. Presentation includes =20 several use cases. Looking for feedback from the working group. Discussion: GRUU draft does have some overlap here - should describe how to do =20 outbound mid-dialog requests. Another disagreed. Path is not replaced in GRUU. Document is needed, =20 but not in GRUU. Question from WG chairs as to whether this should be placed in =20 outbound. Pointed out that this was violently discussed in Vancouver =20 and not agreed. Consensus is that the I-D remains individual, because there is no =20 consensus on the correct solution to this problem. Need to identify =20 which problems need solving, and which ones should be left out. Connection reuse (draft-ietf-sip-connect-reuse) Slides: sip-8.pdf Vijay Gurbani presenting. WG chair identified that Vijay would present the current status of =20 connection reuse, but then move on to an issues that he considered =20 needing resolving in order to complete the work, which was where =20 domain certificates came in. A discussion ensued of Dean's facial hair and whether it has anything =20= to do with the squirrel. Presents current status of work. Draft is essentially complete, =20 however need text on virtual hosting. Discussion: AD: what text is needed on virtual hosting =96 not confident it is =20 possible to write this text? Editor would like to get domain-certs =20 work done first. When returned to the issue: Theory is that research on domain =20 certificates will help solve the problem of virtual servers. No =20 consensus as to whether this work has a future or not. Domain certificates (draft-gurbani-sip-domain-certs) Slides: sip-9.pdf Vijay Gurbani presenting. There is a significant open issue regarding how SIP domains are to be =20= specified in certificates used by proxies for SSL. This issue =20 interacts with practical issues regarding how certificates are =20 obtained, how SSL operates, and the intended security assertions of =20 SIPS/TLS. Discussion: Security advisor: TLS isn't designed to work without a fixed name in =20 the certificate, don't do this, it doesn't work. either buy specific certificate or wildcard - is that what you're =20 trying to accomplish? Security advisior: no matter how many servers you have in your farm, =20 they have one name. Any attempt to do otherwise, you can fight that, =20 but you'll lose. AD: I know we have problems in RFC 3261 - is this one of those =20 problems? Naming things are complicated because they are so =20 arbitrary. We can try to support anything, but some things work =20 better than others for TLS. The combination of credentials and domain =20= names must make sense. TLS is oriented to the existence of a single =20 host name. What is in the domain name must match the certificate (and =20= the credentials they hold). Anything in the Record-Route header must =20 match the domain names of the credentials. usually people expect the name in the certificate to match the =20 hostname. In this case, you're having the same problem - "how =20 meaningful is it when they match"? Can accept broader "matches" if =20 you're asking a user, but there are limits. Presenter identified that the issue is what is a domain name. Is =20 downtown.atlanta.com same as atlanta.com. Others from the floor identified that the way to answer this is to do =20= the multiple names in the certificate. Would like to ride the web way and get certificates that match the =20 host name. Could associate the connection to its name - makes record-=20 route work correctly. AD: "human isn't always involved in matching" - proxies connecting to =20= proxies, etc. All the cases you're showing are easy to match. Do we =20 really need subordination checking for names? Security advisor: don't undertand SIP, do understand security. It's =20 not reasonable to believe you have different security matching for =20 different applications. Could have second name or wildcard in =20 certificate - that's what I'd recommend. sending INVITE to atlanta.com, told to go downtown.atlanta.com. What =20 I want to know is that I got to someone who is authoritative for =20 atlanta.com. But, domain name in the certificate has to match the host you're =20 talking to, otherwise you're talking to someone else. Presenter likes two names in a certificate, too. need something like domain keys from mail world applied to SIP. AD: you have a route header because someone gave it to you. Should we =20= talk about mechanics for an hour here? Could have SIP connection that =20= you can trust, could have SIP connection where you can't trust - =20 depends how you got it. Dean - TLS connections aren't end-to-end, and have nothing to do with =20= request URIs. Therefore the Route header has to contain this =20 information independent of the Request-URI. Issue has more in common with HTTP than you think. =20 downtown.atlanta.com can get a certificate independently of =20 atlanta.com, or could break relationship with no way for atlanta.com =20 to revoke certificate. Security advisor: CAs don't interpret domain names. Verisign doesn't =20 ask apparent delegators about certificates for subdomains. Trying to =20 assume that they do will fail - it failed in HTTP cookies already. The guy you trusted put the URI in there. Wildcards can work, we have enough of a solution, let's stop with that. Back to presentation. How do servers authenticate clients? Which =20 header does it use: From, Via, ... name in certificate. Discussion: AD: Cullen - the name it pulls out of a certificate is the right =20 answer - based on a name, doesn't have to match anything. Make that look like client-server, just in reverse direction. We have =20= to separate authentication from validation. Presenter =96 if we do this, then the proposal has to be to normatively =20= update RFC 3261 in lots of places. Agreement from floor. Document is currently an author draft, and will remain so. SIP session 2 Agenda bash Note takers were identified. Thanks to Be Campbell, A.C. Mahendran =20 and Spencer Dawkins for taking notes for session 2. Need to move a number of items which we failed to deal with on the =20 previous session into this session, therefore we have shortened some =20 of the original items in an attempt to catch up. Location conveyance (draft-ietf-sip-location-conveyance) Slides: sip-2.pdf James Polk presenting. Slide 2: Goal of the draft is to push UAC's location to another SIP =20 element. PUBLISH is not pushing in this definition. Along the way, =20 define SIP as a Geopriv =93Using Protocol=94, per RFC 3693. Incorporate =20= the Geopriv defined PIDF-LO (RFC 4119) into SIP Messaging Slide 3 & 4: Changes since last version. Slide 5: Open issues requiring resolution. Move the requirements to an appendix - this will stay in the RFC. =20 Keith mentioned that the format needs to be consistent with other SIP =20= documents. Only needs to move later in the document and take out the =20 RFC 2119 text. Agreed. Carve out basic operation section without normative text. Re arrange =20 sections 4&5 into per element behaviours Reduce the text in section 2. Agreed. Slide 6: Open issues not sure about. Suggestion to list all SIP methods this extension applies/does-not-=20 apply-to in the abstract. Discussion: Don't want to rule anything out of scope. Could also see some cases =20 where it even applies in SUBSCRIBE. Applies to these types of things, =20= may apply to others" is fine. Don't rule stuff out of scope in this =20 document. Proposed using this in REGISTER during ECRIT yesterday. Hisham - too much text in the abstract for a complete list. Just need to be clearer about pull vs push in Abstract - will say =20 this more clearly on the list. Just improving Abstract text, not changing scope of dcument. Conclusion: Will take to list. Suggestion has been made: For location by value, S/MIME message body =20 always used initially, and to allow a back-off to less secure =20 communication if there is an error. Discussion: For emergency calls, not comfortable increasing setup time. S/MIME only works when encrypted with public key of destination - =20 don't know destination, much less public key. This sounds good but =20 will always fail at least once and may fail in all cases - unable to =20 communicate at all. Conclusion: Good technical reason not to do this. Suggestion: expanding the location header to allow a base64, PIDF-LO =20 equivalent header value i.e. allow the PIDF-LO object to be present =20 in a SIP header (probably, encoded in base64). This goes against past =20= guidance (from both chairs and ADs). Discussion: What was rejected was to embed a PIDF-LO format. AD: Agree that was bad. What proposal in this are is good? Data URL allows for the location to be included in the SIP header. =20 (MIME type and encoding. See no technical reason why it would'nt work.) AD: Putting this sort of information in headers breaks the layering. Useful where location information needs to be resolved into a PIDF-LO =20= document. Message bodies should not be used for call routeing. Headers should =20 be used for this sort of thing. Presenter of the opposite opinion. Referred to minutes of Boston ECRIT interim. Conclusion: WG chairs asked for the discussions to be taken to the =20 list (including discussions on motivations for carrying this =20 information in a header as supposed to the body). Also needs to =20 discuss whether it will work with UDP. Issue: Should location be allowed in responses? Issue: Add a new requirement that HTTP is required to be used by =20 receipient for de-referencing location. Both issues to the list. Presenter requested more reviewers for the draft. WG chair: new version needs to be ready for WGLC. If you have =20 objections or technical comments, now is the time to say so, on the =20 mailing list. SAML for SIP (draft-ietf-sip-saml) Slides: sip-10.pdf Jeff Hodges presenting. Slide 2: Status. Moved to WG document, addressed list feedback from =20 Vijay Gurbani. Enhanced assertion example section; added references; =20 changed order of scope and intro sections; moved use cases in appendix. Slide 3: Issues: Is this spec a soution for only meeting the trait =20 based auth requirements? Discussion about enabling SIP proxies to add =20= SAML assertions to the - If so, only need to meet stated requrements =20 in trait-authz-02 would not need to met reqs of other saml based =20 drafts may need their own saml profiles, doesn't need to meet reqs of =20= various SAML-based I-Ds eg sippayment, SIP CPC, SPIT. SIP header by value. Slide 4: Issues. Discussion about enabling SIP Proxies to add SAML =20 assertions to the SIP header by value. WG chair: Postive responses on the mailing list and therefore =20 accepted as WG draft. Discussion: Yes, it covers the requirements. Concerns about binding of SAML =20 asserting to SIP call. Some fields like Call ID etc need to be in the =20= SAML assertions. Would like to have standalone binding of assertion =20 to the call. Editor (and Jason Fischl) will check to make sure that =20 it is covered. That's a stronger check than any of the saml constraints. Problem is =20 that we're doing something besides just delivering a cert - it's a =20 signature over data. Backwards compatibility issue referencing saml. Server does not know =20 whether to provide a cert or a saml association. Fix is being made in draft-ietf-sip-identity in AUTH48 to allow CID, =20 etc. allow broader choice of URI schemes. Need a way to disambiguate =20 URIs. Conclusion: All issues need to be taken to list. Certificates (draft-ietf-sip-certs) Slides: sip-6.pdf Jason Fischl presenting A good number (lots?) of people seem to have reviewed the draft. A =20 fair number are implementing or intend to implement. Will be at the =20 next SIPIT. Will go to WGLC in a couple of weeks - if you're going to scream, do =20 it really soon, onlist. If you have any comments that will cause a =20 revision, get them on the list quickly. Hop limit diagnostics (draft-ietf-sip-hop-limit-diagnostics) Slides: sip-0.pdf Scott Lawrence presenting. Contrary to what the presenter initially said, this document is not =20 in WGLC, as we are waiting for the charter approval. We have polled =20 to see if it is ready, so we can put the question as soon as the =20 charter comes through. Issues raised during recent discussion: Slide 2: whether "request message" should be returned in other un-=20 recoverable errors (400, 403, 410, 414...). This is not the =20 definitive proposal. The problem is this changes the focus of the =20 draft. Text might say that if an error does not already specify a =20 diagnostic or recovery mechanism, it could do this. Discussion: ok with expanding the scope of the draft to include this for other =20 error message. Not sure if I agree with this list. Generally for =20 proxy-related errors, and for protocol-related failures, not for =20 policy-related failures. Conclusion: No objections in meeting to explanding the scope to =20 include other errors. Slide 3: Is it ok to use Warning header for problems other than SDP? =20 Should we use a specific warning code be defined? IANA registry says "used for =20 SDP". But this isn't what the RFCs said, and. Would make more sense =20 to reuse than pick something else for religious reasons. Discussion: Proposal to put another header in the sipfrag rather than change the =20 Warning header. Henning and Jonathan can't remember any grand architectural =20 justification for the IANA restriction. At that time motivation was =20 mainly SDP. However, see no reason why we cannot reuse it for SIP. Presenter: We're seeing non-SDP bodies for which Warning might apply Will not object. However, text for registry document needs to be =20 changed as well. WG chair asks the SIP WG to think generally about other uses of =20 Warning if we are expanding it to do this, and make sure all intended =20= usages are covered. Conclusion: Ok to using Warning header (to describe issues with =20 bodies generally, but will need to change IANA registry text as well. Comment from floor outside scope of this slide on how some =20 intervening entity can know whether to pass on the contents on this =20 or not, and whether the server knows such an intervening entity =20 exists. Such hiding functionality is outside scope of current SIP =20 work. Assumption is that there is no value in interoperator =20 diagnostics if some hiding function provided at an edge. Document currently uses Warning header 399, which implies no =20 automated action, but some comments have been made that automated =20 responses may be interesting. Slide 4: Should a limit be set on response size? Very large UDP =20 responses may fragement so much that no response reaches the request =20 originator? Should that limit apply to all responses? If yes, what =20 size? There is no documented limit Scott can find on response sizes =20 (request sizes, but not responses). Do we need a response to say my =20 response is too big? Presenter would prefer to duck this issue in =20 this specific draft. WG chair indicated that until this problem is resolved in some =20 manner, then this draft will not progress. Discussion: We could trim off via's, etc. If UAC needs them it can sip trace-route. Presenter: Draft allows exactly that to occur is so wish. Could also =20 strip off mirrored headers. Concern about not being reversable (NAPTR =20= choices, etc.). But repeating the message does not ensure the same path. Different =20 path could create different error. Does not solve general problem of =20 response size. Possible useful things in congestion-safety draft 3261 did not limit response size because at the time, the responses =20 were generally the same size as the requests, so the request limit =20 mostly limited the response. Put lower than MTU size on the request, =20 then hope the response did not grow beyond the MTU size. Presenter: Is this assumption still true. Many SIP assumptions are =20 not true any more. need limit, much larger than request because of Record-Route, etc. =20 How to get fragments through NATs and Firewalls. Why not consider content redirection? Some responses get quite large =20 (488, etc.) - may not even want all this stuff, let proxy store and =20 diagnostics retrieve? Presenter: Is there a likelihood of connecting HTTP seventy hops away? If the response gets fragmented, we could get retransmissions that =20 may be worse than not having the diagnostic info in first place. Not =20 a completely useless response if it tells you to stop retransmitting. Suggestion of a 200 byte limit for diagnostic information. The =20 request limit was chosen assuming that responses would not usually =20 add more than 200 bytes to request size. Last hop before UDP to TCP =20 will be at the size limit. Not an obvious answer on this. Conclusion: Document not ready for WGLC. Editor will introduce at =20 least two threads on issues raised in meeting. No objection to use of =20= Warning header. Message size must go to list. Connected Identity (draft-ietf-sip-connected-identity, draft-elwell-=20 sip-tispan-connected-identity) Slides: sip-15.pdf John Elwell presenting. Slide 2: need for option-tag to indicate UAS support for the identity =20= header field in mid-dialog requests? Saves UPDATE transaction after =20 answer if the AoR is the same as To header. However yet another =20 option tag. Will anyone support id-change without supporting =20 connected-identity? Email suggestion to make it dependent on receipt =20 of id header. Proposal: Don't need new option tag Conclusion: Proposal accepted =96 a new option tag will not be provided. Slide 3: sip-identity is silent on how to behave if identity in =20 "From" header field is not one that authenticated UAC is allowed to =20 assert. Left to local policy, but this policy may be different for =20 mid-dialog requests compared to initial requests. Just add a note =20 saying this? Proposal: Add a note to indicate that it is effectively left to local =20= policy whether to reject or forward without identity header. Discussion: reasonable but applies to Identity draft, too, right? blanket note in draft-ietf-sip-identity about local policy, but isn't =20= after every paragraph. Conclusion: Proposal to add note accepted Slide 4: Should we mandate UPDATE for sending connected-identity =20 rather than reINVITE. Could make 3311 mandatory to support if you =20 support id-change tag. Discussion: what about implementations that don't do update? who can deal with identity should be able to do update Proposal: If you support this extention, you must support UPDATE =20 extension. Conclusion: Accepted Slide 5: Should we mandate inclusion of SDP offer in UPDATE request? =20 Not strictly necessary. But would be signed, in same way that SDP =20 offer in INVITE request is signed Discussion: Only useful if you mandate signed SDP. Up to implementors, but =20 implementors have to deal with the damage. Should call sdp in update =20 out as something you can do, but don't require it. just needs a way for this to be possible Conclusion: Not required. It needs to be optional. Allow this if you =20 wish, but do not require. Slide 6: Should To header field URI in response be allowed to differ =20 from the request? Body of opinion that says that this is an entirely =20 different consideration from the one in Vancouver that led to =20 decision to allow =46rom header field URI to change in mid-dialog =20 requests. No warning in RFC3261 that such a relaxation might occur in =20= the future (unlike the =46rom URI change). Body of opinion that says it =20= would not be useful. Body of opinion that says it doesn=92t harm =20 anything. TISPAN requirements. Leads into requirements from slide 7, slide 8, slide 9, slide 10, =20 slide 11, slide 12 (draft-elwell-sip-tispan-connectedidentity), e.g. =20 TISPAN needs two identies each for caller and callee - one identity =20 is used for billing, the other is used for call-backs. For caller's =20 identities, the proposal is to use PAI (P-Asserted-Inentity) for =20 billing-id, and "From" for call-back-id. For callee's identities, the =20= proposal is to use PAI for one of ids, and there are a number of =20 options for carrying the other identity - To header, "From" of a new =20 UPDATE request from callee to caller, etc. Note written at same time =20 as the identity coexistence draft was put out, so conflicts could not =20= be dealt with. Discussion: TISPAN does not get to change what the identity semantics mean without going through sipchange process. The =20 P-Asserted-ID has well defined values, and TISPAN is trying to change =20= that. TISPAN is not allowed to do this. Keith: Does not redefine P-Asserted-ID - just says what will be put =20 in P-AID. Interop problems with lots of people taking different views. If each =20 group redefines how identities are interpreted, nothing will =20 interoperate TISPAN is just saying that the =46rom header says who the caller thinks =20= he is, P-AID is who the network things he is. TISPAN thinks the =20 different is useful. PSTN does not know the difference, only that P-AID is an =20 authenticated ID. Using PAI for billing. Have the understanding that PAI will be used for callbacks as well. P-=20= Asserted-ID must contain a reachable AOR. P-Asserted-ID has lost focus on what it means. Is being used by =20 enterprises. Hard to know which one to trust. AD: Can we use something like P-Charging-Vector to carry the =20 billing. : This may imply we need a billing ID. Could the 3gpp =20 charging related headers be used? There are real interop issues here =20 on what to use for callback number and caller-id presentation. May =20 need discussion with liaison. May need to spec a real charging =20 vector. Not sure if he has captured the problem. Agrees with that P-Asserted ID doesn't work as a charging vector. =20 There are situations where this make sense when you want to change =20 the callback number. 3 problems: who to bill, who to call back, what sort of subcategory =20 of user is the caller a part of. Proposal: Does the editor fall back and specify requirements around =20 this in tispan-connected-identity? No. The proposed solution is =20 separable and could therefore be covered in another draft and =20 therefore it is separable from the connected identity issue. Conclusion: Connected identity will proceed without this. Further discussions on the mailing list on the TISPAN requirements. Editorial question: Based on RFC 4485 requirement to show real =20 identities, do we need correct values for identity header field, =20 along with a real private key, etc. (as in identity). Cullen Jennings: Please do this, hard to get this correctly and I'll =20 do this for you because it's hard. Still getting this nailed with Jon =20= in AUTH48 for draft-ietf-sip-identity, didn't have the same answer =20 from two separate implementations. Security Flows (draft-ietf-sip-sec-flows) Slides: sip-12.pdf Robert Sparks presenting. Working on creating examples with automated tool. Otherwise getting =20 them right is difficult. Matching certificates rules aren't adequately captured; spread out =20 and not completely clear. This document is not normative, so they =20 will not be captured in this document. WG chair asked if this fed into the security-guidelines draft to be =20 discussed later in the session. AD: Should refer to 2818 rules as often as we can, but RFC 2818 is =20 informational, and this is already hitting drafts now. Will be better =20= when IESG gets the downref rules completed. Lots of implementations match wildcards in DNS names, this is an =20 education issue. On finishing generation of examples, he will shortly submit a draft =20 for WGLC and publication. Addressing the Forking Amplification Vulnerability (draft-ietf-sip-=20 fork-loop-fix) Slides: sip-11.pdf Robert Sparks presenting Slide 2: Latest version demonstrates the attack with one resource and =20= one attacker, rather than multiple attackers. Reintroduces some of =20 the motivational text in the security consideration section (based on =20= conversations with Cullen). Updates the 3261 text on loop detection. =20 Identifies open issues. Added notes to implementers pointing to =20 common interop problems at earlier SIPits. One Suggestion on mailing list not yet in draft: - Don't start loop =20 detection until you've gone around at least once =96 wait until you see =20= yourself earlier in the via stack. This is an optimisation based on =20 normally not going to hit this. Requires extra logic which gives no =20 major advantage. Conclusion: WG agrees that this optimisation will not be included in =20 the draft. Slide 3: In the computed hash, why include all route values, callid, =20 to-tag, from-tag, proxy-require, proxy-authorization headers? Call =20 id, to tag, from tag don't need to be there as they are invariant. =20 Proposal is to leave these out. - why proxy require, proxy auith Discussion: we had reasons for all of these but not written down and no one =20 remembers why. Can think of Proxy-Require justifications, but Proxy =20 knows what header fields it would look at for routing purposes on =20 additional passes - does it really? Presenter: Normatively says anything you are using to compute route =20 goes in the hash=97would cover this case. Conclusion: Will leave items out of hash computation unless something =20= comes up in lists. Send specific issue to list. Feature Creeps - Advancing the SIP Standard - Documenting the feature =20= sets Slides: sip-13.pdf Robert Sparks presenting. Task of identifying the feature sets to advance the standard. Work is =20= just getting started. Want to avoid exponential explosion of must/=20 should/may features, so slide 2 contains an example. There will brain-stroming on this topic in global.sipit.net. Wiki =20 will be used so anybody can participate. The expectation is to have =20 an initial draft by the San Diego meeting. WG chair: Please send out invitation to enable participation in this =20 effort. Discussion: Does progression effort make sense after newtrk discussion. Presenter: Other things motivate this work as well. Building =20 interoperability. Need to make strategic decision on whether a bug-fix doc should =20 become a 3261bis effort. Presenter: Proposal on this coming out later. One motivation is to =20 determine what was stable and what was still rough Useful for feature compliance statements. "compliance to 3261" must/=20 may/should is absurd, need help here, there is value, whether we go =20 to draft or not. Call flows more interesting for implementors. Hitchhiker's Guide (draft-ietf-sip-hitchhikers-guide) Slides: sip-16.pdf Jonathan Rosenberg presenting. Adopted as WG item. Removed SIP family discussion of specifications =20 text; this is out of focus for the SIP WG itself. Redefined what's in =20= scope for the document (MIME usage specific to SIP only, SDP stuff), =20 Redefined what's a core spec =96 something that will be used for every =20= call. Added conferencing topic area, telephony specs, minor =20 extensions. Reference [42] is Hitchiker's Guide book, there's a towel =20= reference. Issue: When is document done? Proposal A: - Split core into a =20 separate document, issue immediately; rest of it goes much later. =20 Proposal B: Keep as one document, pick a point at which we decide to =20 issue, revise later on. Suggestion: Proposal B Discussion: keep together and revise. RFC 4510 all went out as one big chunk for LDAP, but maybe there is =20 experience here. Roadmap which says this is LDAP, but with this =20 document waited until all finished. change the name? need official-sounding name? Presenter disagrees, maybe people don't get the cultural reference =20 but this is not offensive. Consensus on A or B will be determined on the list. Request for comments from editor. SIPS: Guidelines (draft-audet-sip-sips-guidelines) Insufficient time for detailed discussion and will be discussed =20 further in the ad-hoc session to follow this meeting. However WG chairs wanted to gain a view on the need for an =20 informative document to explain what we have and what we mean. =20 Document will not contain any normative changes, which would progress =20= separately. Discussion: More we dig under this rock, uglier the problem becomes. We have a =20 big problem, not sure we can fix them. AD: does anyone think there's NOT a problem? General derisive laughter. The more we get into this work, the more we will realize what less we =20= have got! Francois Audet: Third revision based on list discussion. Does not =20 think we can fix this without normative fixes. Does not believe =20 anyone has successfully implemented SIPS. WG chairs: Any objections to proceeding with an informative document? =20= Will ask ADs to add this to the charter. There was consensus to add this to the charter. SIP Security Breakout Issue Framing by Cullen Jennings We have an interesting problem, based on list review, but there's a =20 lot to look at. Need to pick specific problems. ICON for "secure phone call" - what does that mean? Some is "local =20 policy". Encrypted media? Know who you're talking to? Knowing the =20 person you dialed is the person who answered? Knowing no one snooped =20 your signaling? Some binding between all these things - this is what =20 the "hopping bunny" was about. SIPS: URL does NOT mean ANY of these things. What ciphers are acceptable? Problems for SIP, AVT, MMUSIC... Problems on TLS and SIPS: - bugs and unclarities, see Francois draft. =20= May even have contradictions in specs, need to resolve confusion. A =20 ton of people have "implemented" TLS and even SIPS: but not clear =20 what works. "TLS across all the hops, or almost all, or anything..." =20 Hard to define, retargeting, ... SIP goes one direction with =20 retargeting, but SIPS: never thought about the other direction. Have =20 to decide what we want to do. Have to be symmetric. "Secure" always =20 TLS? See problems with IPsec... Discussion commenced here. Dean - current document problem - no way to know that all nodes =20 complied to the spec in the middle. Brian - we either transitively trusting or we aren't. We have to choose. But we have requirements for end-to-end security, too. Can we assume transitive trust? Jon - if there's a SIPS URI that's signed, that's a comfort at the =20 other end, but it's a small comfort. Can we agree on transitive trust? Simplifies scope but doesn't guarantee solution. Jon - EKR suggested something like SIPS in the document (RFC 3261), =20 and this was late in the process, threat model pretty much worked out =20= but SIPS inserted quickly (too quickly? and carelessly). Probably a =20 number of problems to address. draft-audet-sip-sips-guidelines-02 "At best underspecified" and probably wrong. Started 00 to explain =20 how we were right ("we're the IETF"), and every version of the draft =20 gets worse. Need to make some decisions pretty soon. People are developing this =20 now. Implementations don't have that much to do with 3261. Vijay - specific problems - upgrade/downgrade, transport=3Dtls =20 (deprecated). Can be implemented, but there are problems. Six sections in the draft - meaning of SIPS, upgrading/downgrading, =20 SIPS registration, SIPS dialog, transport=3Dtls, a lot of other issues =20= (GRUU, outbound, REFER, background). Meaning of SIPS - TLS for each hop until terminating domain. Jonathan - intent is that last link is secure (somehow). Biggest problem is that we're not symmetrical for reverse path - in-=20 dialog requests cannot work. Does not mean a Padlock icon, requires Record-Route or things get =20 dangerous quickly with SIPS Contacts. Jon - issue was assumption that UA would not be able to accept =20 incoming TLS connections - and assume that the reverse path would =20 work the same way ("secure in some sense"). "Support SIPS" is "support TLS connection to remote first-hop proxy". The part that's broken is that people assume UAs don't have to =20 support SIPS. They do, in order to make outgoing calls. Dean - Proxy is SIPS/SIP converter (in Dean's remembered vision). Record-Route and Contact interaction is not limited to SIPS. Jon - once we have outbound, we're in a position to do this right. Discussion of suggestions from list: deprecate SIPS altogether, =20 deprecate last-hop exception (not sufficient alone), explain the =20 exception and fix the bugs that result. Draft assumes third choice, =20 but lots of people like deprecating last-hop exception. People liked =20 deprecating SIPS, too... Noted that we need to accommodate 3GPP here. Do people think we should deprecate SIPS? More chaos, people have =20 implemented SIPS. Juha said "broken for now" note until we fix it - =20 Francois' draft is that note :-) Don't think SIPS works at all on a business card, or in to/from. =20 Can't use a padlock hop-by-hop. What does "deprecate" mean? Telling someone that SIPS will almost =20 never work? EKR - point of SIPS is to provide given level of security. Does it =20 work? Problem is TLS ending at proxy. Scott - "SIPS is broken"? Want to be able to say a particular =20 connection must be made over TLS. Sometimes, that's the only thing =20 that works. Need to be able to say "secure" about particular hops. Jonathan - we have many documents with "use SIPS" as security =20 considerations for relationships between proxies and clients. That is =20= reasonably useful, even if it's not end-to-end, even if you need to =20 trust middleboxes. Francois - can't deprecate, too pervasive. What do we expect to get out of SIPS? Need to know this to know if =20 it's useful. There is a real threat being solved, preventing people snooping or =20 modifying requests. This is everywhere in the document set. "Use SIPS" is the "use IPSEC" =20= of SIP. Don't need to change the meaning of SIPS in this group. Need to focus =20= on the real problems - last-hop, explanation Jon gave at beginning of =20= the meeting. EKR - wouldn't it be great if we had end-to-end security, or even =20 integrity? In SIP, like it or not, trust model is that proxies can =20 screw you anyway they want. With that, SIPS is useful, but not for =20 lock displays. Scott - agree with EKR, start by explaining the meaning of SIPS. =20 Clarify whether it's about signaling, and how far. Doesn't cover =20 media (which is what people actually think about, and a totally =20 different problem). I want TLS protection until I get to something =20 with the certificate that matches the request URI. I understand =20 semantics are different but think this needs to be clarified. =20 Francois has made a start at this. Options - deprecate SIPS, explain what SIPS means, allow transport=3Dtls. We have consensus that we will not deprecate SIPS. Transport=3Dtls was formally deprecated, but no one believes this and =20= many/most implementations still understand and will use this. Allows for "best effort" hop-by-hop TLS usage. Endpoints that cannot =20 have a DNS entry can't have own certificates anyway. (Also need to add a transport=3Dtls-sctp (like Via) - would be more =20 consistent, too) Jon is confused here. how to start supporting TLS for one hop? But =20 this isn't about SIPS right now, right? We'll table this now. Registration issue: Some people infer "must use TLS on REGISTER", etc. from current =20 documents. Registration: AOR - SIP implies SIPS, this is a big problem since =20 many, if not all, UAs cannot process SIPS URIs. New way to explicitly =20= register SIP only? If you only register SIPS, you haven't registered SIP - this is not =20 symmetrical, either (more comfortable with upgrading than =20 downgrading?) Is this broken? Not sure why we're indicating that you =20 have only one or the other AOR... Interaction with Outbound - create a TLS path to home proxy, so proxy =20= can send either SIP or SIPS to you over TLS ) which is what you're =20 asking for. SIP and SIPS as separate registrations? Cullen - this would always =20 work. Can we imply an upgrade path where one always implies the =20 other? Which way? Francois - not backward compatible. If you send SIPS to most clients =20 you'll be in trouble. This is an AOR, right? It's equivalent to being =20= a different user. Or at least using a different port. Jon - great explanation by Jonathan but that's not in 3261 - Jonathan =20= agrees, this is the way to move forward. "URIs are never equivalent" =20 text does exist, but so does text that says both need to exist as =20 aliases. Francois - some people are thinking you should derive reachability =20 from the transport you used for your registration. EKR - SIPS means "TLS all the way somewhere". SIP means "maybe over =20 TLS, maybe not", and can't expect people downstream to use TLS or it =20 may not work. Does it matter which AOR you use? Jon - if you're registering a SIP URI, can't expect you'll be able to =20= do SIPS. Francois - if you don't use outbound, what does this mean? Jon - use whatever channel you've got. Francois - was assuming the opposite (SIPS would imply only SIPS, SIP =20= would imply both). Registration contacts - list explicitly all valid transports, using q-=20= values? Jonathan - clarifying 3261 without changing it, right? Pointless. =20 Let's start over and do this requiring SIP outbound. Jon - Outbound isn't done yet. Jonathan - This is done first? Proposal - write a standards-track document that fixes 3261 and =20 requires outbound? Keith - need to look closely at normative change process - do =20 guidelines document PLUS fixing 3261 document. Francois - need to agree on normative changes - then we can split. Aki - I like SIP in contacts, to, from. With outbound, contact =20 doesn't matter anyway. Don't put it in to/from/contact. Paul - when do we get clarification? No one knows what it will take =20 to fix this stuff (or at least not sure you're talking about the same =20= thing). Francois - don't pretend every statement in 3261 is correct. Jonathan - we have 200 bugs in Bugzilla - why would we question this? Jason - SIPS:transport=3Dtcp? Robert - what does that mean in a route header? TLS one hop away? Scott - back to the current definition of how many hops you use TLS =20 (until you reach the named destination domain). Jonathan - have proposed change to location lookup - add route =20 header. We screwed this up in 3261? Scott - if you let UA register SIPS URI with non-SIPS contact, that's =20= an explicit action on the part of the user. Cullen - I think I agree here. How to deal with Contacts in REGISTER, Record-route, contact in =20 dialog... Jon - hum on fixing 3261 instead of apologizing? Francois - thought we were making a proposal to fix in next revision. Next steps - to list. Jon - need to know how this works with outbound in order to make =20 recommendations. draft-gurbani-sip-sipsec-00.txt Do SIPS the way HTTPS works - end-to-end upgrade? EKR - HTTPS blows through proxies, "get out of my way". Not what =20 we're talking about now. Cullen - if we didn't Record-Route, we'd get the same thing in SIP. Cullen - Dean arguing for something that only works if there are no =20 proxies. Interesting, scenario does exist, but this isn't the main =20 case. This is why we don't encrypt headers. EKR - 18 proxies between point A and point B are there for a reason, =20 not just forwarding packets. We'll talk about this more on Friday afternoon (at P2P-SIP). Vijay - we talked about this on the list, and there are people who =20 want their proxies to stay involved. Cullen - most of the proxy twiddlings are in 3261 as threats, and the =20= answer was "use end-to-end security". EKR - this creates a generic NAT traversal server mechanism. Once =20 you're in TLS, go crazy. There's like one proxy between you and an =20 HTTPS server. draft-srivastava-sip-e2e-ciphersuites-00 Led by Samir Srivastava Slides presented. Principle argument: Level of security is missing. SIPS is a mess. =20 Should DTLS be considered as well? Proposal: Extend Via to include Ciphersuites, define header for =20 desired cipher-suites, secure protocol, etc. EKR has an alternative solution - let TLS take care of ciphersuites =20 at each hop, rely on mandatory-to-implement as common-denominator, =20 trust proxies for mandatory upgrade/downgrade. Jonathan - with EKR on this one, proxies can do so many things that =20 are worse. SS thinking of catching evil proxies more quickly, allow UAC to =20 control ciphersuite selection. SIP Security advisor says there's a hole in this. Would Security ADs =20 pass this document? EKR - current security is worse, right? Dean - this catches stupid proxies. Evil proxies lie. EKR - in TLS, your client has no control over what the server =20 actually chooses, right? Proxies doing DTLS to TLS need to know ciphersuites for other protocols. Open issues - which solution to pick? Partial adoption with SIPS? =20 Impact of renegotiation of ciphersuites needs to be analyzed? Has anyone else read the draft? 5 or 6. Anyone who might implement? John - I thought so, not so sure now if we're trusting proxies. Dean - need a mechanism for Proxy A and Proxy C to keep an eye on =20 Proxy B - this could be it. Discussions about SIP and TLS don't state problems and then argue =20 about details, so never come to conclusions. Need starkly clear =20 statement of problem and benefit to users. Conclusion: Please respin, focusing on problem statement, and we'll =20 look at this again. --Apple-Mail-4-244972171 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252

Ok, folks. Here's the first pass at the minutes for IETF 66.=A0 = Please excuse the HTML, but it seems to be fashionable for the = proceedings.

They're also webbed at:

http://www.softarmor.com/sipwg/meets/ietf66/notes/minutes-sip-iet= f66.html

Please respond with any corrections on the = list.


Session = Initiation Protocol (SIP) WG

Minutes edited by Keith Drage, with Security Breakout edited = by Dean Willis

Based = on notes by Bruce Lowekamp, Dale Worley, Ben Campbell, A.C. = Mahendran=A0 = and Spencer = Dawkins.

Meeting = chaired by Dean Willis and Keith = Drage.

Slides = presented included in the = proceedings.

SIP session 1

Agenda bash and current = status

The = note well statement was displayed

Slides: = SIP-1.pdf

Note = takers were identified. Thanks to Bruce Lowekamp, Dale Worley and = Spencer Dawkins for taking notes for session = 1.

It was identified that there was expected to be an ad-hoc SIP = session on the security issues that were being found with RFC 3261, in = regard toSIPS usage.

The = agenda was agreed with the insertion of a quick slide from Gonzalo = Camarillo on SIGCOMP activities.

The following SIP RFCs were identified to have been published = since IETF#65:

  • RFC 4458: Session = Initiation Protocol (SIP) URIs for Applications such as Voicemail and = Interactive Voice Response (IVR) =96 AD sponsored = informational
  • RFC 4483: A = Mechanism for Content Indirection in Session Initiation Protocol (SIP) = Messages =96 Proposed standard
  • RFC 4485: Guidelines for Authors of = Extensions to the Session Initiation Protocol (SIP) =96 = Informational
  • RFC 4488: = Suppression of Session Initiation Protocol (SIP) REFER Method Implicit = Subscription =96 Proposed standard
  • RFC 4508: Conveying Feature Tags with the = Session Initiation Protocol (SIP) REFER Method =96 Proposed = standard
  • RFC 4538: Request = Authorization through Dialog Identification in the Session Initiation = Protocol (SIP) =96 Proposed standard

The following SIP internet-draft was = currently in AUTH48:

  • draft-ietf-sip-identity-06

The following SIP internet-draft was = currently in RFC editor's queue:

  • draft-ietf-simple-event-list-07 (although this was developed in = SIMPLE it was submitted to IESG via SIP to cater for the SIP change = process)

The following SIP = internet-draft are currently with IESG

  • draft-ietf-sip-mib-11
  • draft-ietf-sip-e2m-sec-02

The following SIP = internet-draft is ready for IESG

  • draft-ietf-sip-answermode-01

The following SIP = internet-drafts are in working group last call

  • draft-ietf-sip-connect-reuse-05
  • draft-ietf-sip-gruu-09 (REVIEWERS REQUIRED TO FINISH as only two = WG members identified they had fully reviewed the draft =96 this will be = the first document to go through the full review process identified by = the WG chairs to the list)
  • draft-ietf-sip-fork-loop-fix-02

Existing = milestones were identified, along with new dates for the existing = milestones (with the new separation of WGLC start dates and IESG = submission dates for each internet draft being progressed to = RFC.

In response to a = question from the floor, this leaves 9 charter items the SIPWG currently = has in progress. This was targeted at identifying when the SIP WG would = complete its current work.

At this point the WG chairs identified the = new WG items that were identified by the WG at IETF#65 and subsequent = email activity which identified dates through to the end of 2007. These = were still subject toapproval by the IESG as the WG chairs had only got = the list to the IESG secretary late the previous = week.

In response to = another question from the floor as to whether the dates could be earlier = (specifically for location conveyance), the WG chairs agreed that dates = could always be earlier, providing the WG was satisfied that the = document was actually ready. However the WG chairs stated that this = represented their best estimate of what was = realistic.

The WG chairs then = conducted some polls concerning support for some of the current = work:

  • Question regarding draft-ietf-sip-certs: = Response to list poll was universally positive, but offline WG chair had = had some negative comments. Is this leading toward implementation? = Consensus: Yes, at least 5 implementations are expected from the room, = and no one presenting objections.
  • Question regarding = draft-ietf-sip-connection-reuse. Does it still provide any benefit. WG = chairs identified there was a positive response to the list poll. = However in the meeting one WG member questioned the value based on the = limited number of scenarios where it provides real benefit. It = purported to give CPU overhead benefit, which = the speaker doubted. = Additionally does not work through NAT and = requires mutual TLS to work. Is it the highest priority for the minimal = value it provides. A second speaker identified one advantage is that it = states that any entity has to reuse the existing connection which is not = currently stated elsewhere. Discussion deferred to agenda item on the = topic.
  • Question regarding = draft-ietf-sip-outbound: Should it be revised?

At this point the WG chair projected a = picture of a strikingly flattened-looking squirrel on a flagstone patio. = After the audience expressed some distress, he remarked that this is a = natural phenomenon, the temperature at the time was 45 C and the = squirrel is cooling its belly on the stones. Discussion of = aboreal rodents ensues upon presentation of the = agenda.

  • Question regarding = draft-ietf-sip-outbound: Is it ready for WGLC? Consensus: There are a = number of open issues that still need to be resolved.

SIP and SigComp = (draft-ietf-rohc-sigcomp-sip-02.txt)

Gonzalo Camarillo presenting.

Slides: = sip-3.pdf

Presentation on problem with compression and = record-route. When receiving a request, how to identify the previous SIP = hop that sent the request (in order to manage the compression status)? = Plea for support in resolving this issue.

Outbound = (draft-ietf-sip-outbound)

Rohan Mahy presenting.

Slides: sip-5.pdf

Slide 2: = Currently when STUN response indicates change in mapped address, UA = assumes NAT rebooted and reregisters immediately. There is no = authentication of these STUN keepalives. UDP problem. On unprotected = 802.11 networks, an attacker who can see the STUN request, can easily = send a response with a different mapped address and will usually beat = the real response. This causes UA and registrar (and intervening = proxies) to do work. Can melt the registrar. Proposal to add timer = delaying re-registration if binding appears to change more than seems = reasonable in some period.

Discussion from floor:

  • 3489bis (draft not yet submitted) mentions = issue with forged STUN binding response in security considerations. = Questioned as to whether this is really an amplification = attack?=A0Especially compared to problems with multiple = responses to a single request.
  • don't care if we = reapply the existing timer mechanism but don't introduce new = ones. = There are better attacks that can be = applied.
  • Presenter offers beer for a better = attack.
  • Reference to http://www.usenix.org/events/sec03/tech/bellardo.html

Conclusion: Do not add new = timer.

Slide 3: = Discoverting STUN support. Current text says that keepalive STUN support = is "configured" (using a very broad definition of configure). = Incompatible with current DHCP proxy discovery (but so is sigcomp) due = to limitation of DHCP option. Do we need another way of = discovering/probing for STUN support defined in this document? Options: = provide DHCP capability, provide DNS based option, or provide some sort = of probe mechanism within SIP.

Discussion from floor:

  • Suggestion of Proxy-Require, but this only = allows validation, not discovery.
  • One speaker said = his feedback was that something will turn this on or off, not worth = delaying to define something too complicated = anyway.
  • Another speaker. Jonathan was proposing STUN=3Dkeepalive, right? = Really like this one, because configuring in the phone is key to getting = deployment anyway.

Consensus was considerable support for the rule that = "configuration information is enough to send STUN" but most would like = some direct validation mechanism = created.

Slide 4: = Validating STUN support. Currently presence of keepalive=3Dstun used as = indicator its OK to send STUN requests. Some expressed concern about = misconfiguration causing proxies that don=92t do STUN to get confused. = More of a problem for TCP. Options: treat this as a non-problem; revisit = STUN keepalives over TCP problem; don=92t send STUN until UA validates = its OK, by including a parameter in reflected Path, but Path not always = present; have UA try the request with a Proxy-Require: sip-stun; probe = with OPTIONS. only way to validate = keepalive=3Dstun

next = issue: validating stun support.

Discussion from floor:

  • Proposal that need Proxy-Require "outbound" = would solve this problem rather than Proxy-Require = "sip-stun".
  • If we don't solve LR problem won't solve = this. Agree with proposal
  • any objections must explain why different = than "lr" problem
  • Concern that the mailing list combatants on = these issues are not present in the room; this will have to go to the = mailing list.=A0 = we should ask for positive assents.
  • Another speaker. = Every other extension has a way to reject, this one = doesn't.

Question put to whether document should be changed in respect of = this issue. No consensus.

Back to validation (slide 3). More = discussion:

  • Validation concerns are about confusing next-hops with = misconfiguration, especially for TCP. Is this a = problem?
  • Another speaker. If you put this in the service-route, I'll be = happy.
  • validating:: third option on validating slide would render = discovery moot (don't send stun until validated OK through parameter in = reflected path)

Put to = meeting: is the existence of a keepalive=3Dstun in UA configuration = sufficient to allow transmission of stun without further validation and = progress document with that assumption? No clear consesus with very few = responses. Take to a later discussion, and possibly on = list.

Discussion:

  • It's the service providers, not the = implementers who have a problem with this.
  • Another speaker = (service provider) would prefer not to receive protocol (STUN) that it = doesn't support rather than have to deal with = it.
  • Proposal to add words of caution and admonition, but then let = document o forward
  • Query as to real problem. Identified that can = cause framing problem in TCP. However though that this may be self = limiting.

WG = chairs declare there is not sufficient consensus on either of these two = issues (slide 3 and slide 4).

Slide = 5: STUN keepalive = definition. Proposal that STUN keepalive description is pulled into a = separate section that can be implemented independently. No objection = from floor.

Slide = 6: How many flows = (minimum)?: Current draft says (from Section 4.2): For each outbound = proxy URI in the set, the UA MUST send a REGISTER in the normal way = using this URI as the default outbound proxy. Proposed to change to = SHOULD.

Discussion:

  • SHOULD must have caveat that violation can kill = reliability.
  • Fine, but can't say "does no = harm"=A0 = because single flow causes more aggressive reregistration = avalanche restart problems

Consensus: Agreed to change to SHOULD - but there should be = strong warnings in the RFC of the dangers of not adhering to the = requirement.

Slide 7: = Additional discovery and semantics of outbound-proxy-set. Various = proposals to discover or manufacture outbound-proxy-set or apply = different semantics. We don=92t even have all the requirements written = down for these proposals. Proposal: Can be addressed in future = extensions without any changes to outbound. No dissent from = floor.

Slide 8: Why does = registrar send to edge proxy over same connection? Only needed if EP is = in a foreign domain for authorization. Draft defines edge proxy = obliquely as in a foreign domain, and other proxies as a disaggregation = of a proxy/registrar. Incredibly confusing. Needs to be more explicit. = Request made by presenter for assistance in providing = text.

Slide 9: = How to verify edge proxy support. Currently draft says that edge proxy = adds a flow token to a Path header and forwards. No discussion about how = the registrar decides that edge proxy actually did this. Proposal: edge = proxy adds new parameter "ob" to Path URI to indicate it added flow = token appropriately. Example: Path: <sip:token@ep.example.com;lr;ob>. = If no token present, registrar ignores reg-id parameter, doesn=92t = return Supported: outbound.

Discussion:

  • Will only be = provided for first element. It is a Proxy-Require dodge. Thinks OK.

No time for = further discussion in meeting so editor makes plea to discuss = offline.

Slide = 10: Presence of = Supported: outbound. What does this mean? Today it means that the = registrar supports outbound. Client can use this to understand that if = it needs to cleanup old Contacts using RFC 3261 style matching. = Proposals: clarify this in the text; only include Supported: outbound if = any edge proxy supports outbound as well

re-registering vs replacing = flows:

Discussion:

  • What happens when edge proxy supports = outbound but registrar does not? Would the edge proxy change it's = behaviour. Presenter doesn't see any need to do anything = differently.

No = objection from meeting.

Slide = 11: Re-registering = with same reg-id. Original intent of reg-id is so that UA can indicate = if it wants to add a new flow or to replace an existing flow. Dave Oran = asked for change to language (ex: SHOULD replace) to allow for a private = use case. WG was later uncomfortable with idea of deleting/replacing = flows. In Dallas seemed to have consensus to use most recent flow. Since = then, many complaints on the mailing list about this, and no one = motivating/defending previous choice. Problems with this: proxy can send = traffic to the wrong place (for UDP flows); no way for registrar to = delete state until registration expires; no way for UA to say it really = wants to replace flow; harder to implement on registrar; not motivated = by requirements. Options: leave draft as is; change back to SHOULD = replace flows with same reg-id; say registrar MUST replace flows with = same reg-id. Proposal: SHOULD replace flows.

Discussion:

  • keeping flows is very bad with = amplification.
  • Surely registrar can get rid of state at any = time.
  • new draft almost forces replacement. If two registrations are = equal, one must replace the other. "not a MUST, it's true by = definition".

SHOULD = vs MUST:

SHOULD: = some

MUST: = more

OBJECT = TO MUST: one

OBJECT = TO SHOULD: more

WG = chair: rough consensus on MUST.

Slide = 12: Refresh = registration on same flow. Erkki pointed out that registration refresh = should happen over the same flow it refreshes. No = issue.

Slide 13: = Usage of 410 response Code. Adam Roach pointed out that semantics of 410 = response code is inconsistent with our usage. Proposal: Use 480. No = issue.

Outbound discovery (draft-koivusalo-sip-outbounddiscovery)

Slides: = sip-7.pdf

Miguel = Garcia presenting.

Problem = definition, requirements, solutions, evaluation and specification - all = in one small document.

Discussion:

  • proposal (not sent to list yet) - could DATA = URI be used with maximum number-of-flows in = DNS?
  • Concerns that we are dispersing configuration information to 17 = different places with no architecture supporting this. Why not put it = all in DNS and forget the configuration framework that's not going = anywhere in five years anyway?
  • Concerns expressed = about DNS approach, especially with mid-dialog failure - this won't work = for mid-dialog failure, no way to express this in something as static as = DNS. Getting k of N from a DNS starts to fail with the DNS = design.=A0 = Proper choices can't be expressed in DNS (choose one of first two = and one of second two). DNS is too = static.

Jonathan Rosenberg will write up description of alternative = approach, after which the issue can be = discussed.

Adopt = as WG draft? No decision to be made at meeting. Will take this to the = list to discuss.

Use Case for Mid Dialog Request Routing with Outbound = (draft-johns-sip-outbound-middialog-draft)

Slides: = sip-4.pdf

Sumanth = Channabasappa presenting.

Explores enabling failover when middle boxes fail, and its = interaction with the outbound flow mechanism. Presentation includes = several use cases. Looking for feedback from the working = group.

Discussion:

  • GRUU draft does have some overlap here - = should describe how to do outbound mid-dialog = requests.
  • Another disagreed. Path is not replaced in = GRUU. Document is needed, but not in = GRUU.

Question from WG chairs as to whether this should be placed in = outbound. Pointed out that this was violently discussed in Vancouver and = not agreed.

Consensus is that the I-D remains individual, because there is no = consensus on the correct solution to this problem. Need to identify = which problems need solving, and which ones should be left = out.

Connection reuse (draft-ietf-sip-connect-reuse)<= /SPAN>

Slides: = sip-8.pdf

Vijay = Gurbani presenting.

WG = chair identified that Vijay would present the current status of = connection reuse, but then move on to an issues that he considered = needing resolving in order to complete the work, which was where domain = certificates came in.

A discussion ensued of Dean's facial hair and whether it has = anything to do with the squirrel.

Presents current status of work. Draft is essentially = complete, however need text on virtual = hosting.

Discussion:

  • AD: what text is needed on virtual hosting =96 = not confident it is possible to write this text? Editor would like to = get domain-certs work done first.

When returned to the issue: Theory is that research on domain = certificates will help solve the problem of virtual servers. No = consensus as to whether this work has a future or = not.

Domain certificates (draft-gurbani-sip-domain-certs)

Slides: = sip-9.pdf

Vijay = Gurbani presenting.

There = is a significant open issue regarding how SIP domains are to be = specified in certificates used by proxies for SSL. This issue interacts = with practical issues regarding how certificates are obtained, how SSL = operates, and the intended security assertions of = SIPS/TLS.

Discussion:

  • Security advisor: TLS isn't designed to work = without a fixed name in the certificate, don't do this, it doesn't = work.
  • either buy = specific certificate or wildcard - is that what you're trying to = accomplish?
  • Security advisior: = no matter how many servers you have in your farm, they have one name. = Any attempt to do otherwise, you can fight that, but you'll = lose.
  • AD: I know we have problems in RFC 3261 - is this one of those = problems? Naming things are complicated because they are so arbitrary. = We can try to support anything, but some things work better than others = for TLS. The combination of credentials and domain names must make = sense. TLS is oriented to the existence of a single host name. What is = in the domain name must match the certificate (and the credentials they = hold). Anything in the Record-Route header must match the domain names = of the credentials.
  • usually people expect the name in the = certificate to match the hostname. In this case, you're having the same = problem - "how meaningful is it when they match"? Can accept broader = "matches" if you're asking a user, but there are = limits.
  • Presenter identified that the issue is what is a domain name. Is = downtown.atlanta.com same as atlanta.com.
  • Others from the = floor identified that the way to answer this is to do the multiple names = in the certificate.
  • Would like to ride the web way and get = certificates that match the host name. Could associate the connection to = its name - makes record-route work = correctly.
  • AD: "human isn't always involved in matching" = - proxies connecting to proxies, etc. All the cases you're showing are = easy to match. Do we really need subordination checking for = names?
  • Security advisor: = don't undertand SIP, do understand security. It's not reasonable to = believe you have different security matching for different applications. = Could have second name or wildcard in certificate - that's what I'd = recommend.
  • sending INVITE to atlanta.com, told to go = downtown.atlanta.com. What I want to know is that I got to someone who = is authoritative for atlanta.com.
  • But, domain name = in the certificate has to match the host you're talking to, otherwise = you're talking to someone else.
  • Presenter likes = two names in a certificate, too.
  • need something = like domain keys from mail world applied to = SIP.
  • AD: you have a route header because someone gave it to you. = Should we talk about mechanics for an hour here? Could have SIP = connection that you can trust, could have SIP connection where you can't = trust - depends how you got it.
  • Dean - TLS = connections aren't end-to-end, and have nothing to do with request URIs. = Therefore the Route header has to contain this information independent = of the Request-URI.
  • Issue has more in common with HTTP than you = think. downtown.atlanta.com can get a certificate independently of = atlanta.com, or could break relationship with no way for atlanta.com to = revoke certificate.
  • Security advisor: CAs don't interpret domain = names. Verisign doesn't ask apparent delegators about certificates for = subdomains. Trying to assume that they do will fail - it failed in HTTP = cookies already.
  • The guy you trusted put the URI in = there.
  • Wildcards can work, we have enough of a solution, let's stop with = that.

Back to = presentation. How do servers authenticate clients? Which header does it = use: From, Via, ... name in = certificate.

Discussion:

  • AD: Cullen - the name it pulls out of a = certificate is the right answer - based on a name, doesn't have to match = anything.
  • Make that look like client-server, just in = reverse direction. We have to separate authentication from = validation.

Presenter =96 if we do this, then the proposal has to be to = normatively update RFC 3261 in lots of places. Agreement from = floor.

Document is currently an author draft, and will remain = so.

SIP session 2

Agenda bash

Note takers were identified. Thanks to Be Campbell, = A.C. Mahendran and Spencer Dawkins for taking notes for session = 2.

Need to move a number of items which we failed to deal with = on the previous session into this session, therefore we have shortened = some of the original items in an attempt to catch = up.

Location conveyance = (draft-ietf-sip-location-conveyance)

Slides: sip-2.pdf

James = Polk presenting.

Slide 2: = Goal of the draft is to push UAC's location to another SIP element. = PUBLISH is not pushing in this definition. Along the way, define SIP as = a Geopriv =93Using Protocol=94, per RFC 3693. Incorporate the Geopriv = defined PIDF-LO (RFC 4119) into SIP Messaging

Slide 3 & 4: Changes since last = version.

Slide 5: Open issues = requiring resolution.

  • Move the requirements to an appendix - this will stay in the RFC. = Keith mentioned that the format needs to be consistent with other SIP = documents. Only needs to move later in the document and take out the RFC = 2119 text. Agreed.
  • Carve out basic operation section without = normative text. Re arrange sections 4&5 into per element = behaviours
  • Reduce the text in = section 2. Agreed.

Slide 6: Open issues not = sure about.

Suggestion to list all SIP methods this extension = applies/does-not-apply-to in the abstract.

Discussion:

  • Don't want to rule anything out of scope. = Could also see some cases where it even applies in SUBSCRIBE. Applies to = these types of things, may apply to others" is fine. Don't rule stuff = out of scope in this document.
  • Proposed using = this in REGISTER during ECRIT yesterday.
  • Hisham - too much = text in the abstract for a complete list.
  • Just need to be = clearer about pull vs push in Abstract - will say this more clearly on = the list.
  • Just improving Abstract text, not changing = scope of dcument.

Conclusion: Will take to list.

Suggestion has been made: For location by value, S/MIME = message body always used initially, and to allow a back-off to less = secure communication if there is an error.

Discussion:

  • For emergency calls, not comfortable = increasing setup time.
  • S/MIME only works when encrypted with public = key of destination - don't know destination, much less public key. This = sounds good but will always fail at least once and may fail in all cases = - unable to communicate at all.

Conclusion: Good technical reason not to do = this.

Suggestion: = expanding the location header to allow a base64, PIDF-LO equivalent = header value i.e. allow the PIDF-LO object to be present in a SIP header = (probably, encoded in base64). This goes against past guidance (from = both chairs and ADs).

Discussion:

  • What was rejected was to embed a PIDF-LO = format.
  • AD: Agree that was bad. What proposal in this are is = good?
  • Data URL allows for the location to be included in the SIP = header. (MIME type and encoding. See no technical reason why it would'nt = work.)
  • AD: Putting this sort of information in headers breaks the = layering.
  • Useful where location information needs to be = resolved into a PIDF-LO document.
  • Message bodies = should not be used for call routeing. Headers should be used for this = sort of thing.
  • Presenter of the opposite = opinion.
  • Referred to minutes of Boston ECRIT = interim.

Conclusion: WG chairs asked for the discussions to be taken to = the list (including discussions on motivations for carrying this = information in a header as supposed to the body). Also needs to discuss = whether it will work with UDP.

Issue: = Should location be allowed in responses?

Issue: = Add a new requirement that HTTP is required to be used by = receipient

for = de-referencing location.

Both = issues to the list.

Presenter requested more reviewers for the = draft.

WG = chair: new version needs to be ready for WGLC. If you have objections or = technical comments, now is the time to say so, on the mailing = list.

SAML for SIP (draft-ietf-sip-saml)

Slides: sip-10.pdf

Jeff Hodges presenting.

Slide 2: Status. Moved to WG = document, addressed list feedback from Vijay Gurbani. Enhanced assertion = example section; added references; changed order of scope and intro = sections; moved use cases in appendix.

Slide 3: Issues: Is this = spec a soution for only meeting the trait based auth requirements? = Discussion about enabling SIP proxies to add SAML assertions to the - If = so, only need to meet stated requrements in trait-authz-02 would not = need to met reqs of other saml based drafts may need their own saml = profiles, doesn't need to meet reqs of various SAML-based I-Ds eg = sippayment, SIP CPC, SPIT.

SIP = header by value.

Slide 4: = Issues. Discussion about enabling SIP Proxies to add SAML assertions to = the SIP header by value.

WG = chair: Postive responses on the mailing list and therefore accepted as = WG draft.

Discussion:

  • Yes, it covers the requirements. Concerns = about binding of SAML asserting to SIP call. Some fields like Call ID = etc need to be in the SAML assertions. Would like to have standalone = binding of assertion to the call. Editor (and Jason Fischl) will check = to make sure that it is covered.
  • That's a stronger check than any of the saml = constraints. Problem is that we're doing something besides just = delivering a cert - it's a signature over data.
  • Backwards compatibility issue referencing = saml. Server does not know whether to provide a cert or a saml = association.
  • Fix is being made = in draft-ietf-sip-identity in AUTH48 to allow CID, etc. allow broader = choice of URI schemes. Need a way to disambiguate = URIs.

Conclusion: All issues need to be taken to = list.

Certificates (draft-ietf-sip-certs)

Slides: sip-6.pdf

Jason Fischl presenting

A good number (lots?) of people seem to have reviewed the = draft. A fair number are implementing or intend to implement. Will be at = the next SIPIT.

Will go = to WGLC in a couple of weeks - if you're going to scream, do it really = soon, onlist. If you have any comments that will cause a revision, get = them on the list quickly.

Hop limit diagnostics = (draft-ietf-sip-hop-limit-diagnostics)=

Slides: = sip-0.pdf

Scott = Lawrence presenting.

Contrary to what the presenter initially said, this document is = not in WGLC, as we are waiting for the charter approval. We have polled = to see if it is ready, so we can put the question as soon as the charter = comes through.

Issues = raised during recent discussion:

Slide 2: whether "request = message" should be returned in other un-recoverable errors (400, 403, = 410, 414...). This is not the definitive proposal. The problem is this = changes the focus of the draft. Text might say that if an error does not = already specify a diagnostic or recovery mechanism, it could do = this.

Discussion:

  • ok with expanding the scope of the draft to = include this for other error message. Not sure if I agree with this = list. Generally for proxy-related errors, and for protocol-related = failures, not for policy-related = failures.

Conclusion: No objections in meeting to explanding the scope to = include other errors.

Slide 3: Is it ok to use = Warning header for problems other than SDP? Should = we

use a specific warning code be defined? IANA registry says = "used for SDP". But this isn't what the RFCs said, and. Would make more = sense to reuse than pick something else for religious = reasons.

Discussion:

  • Proposal to put another header in the sipfrag = rather than change the Warning header.
  • Henning and = Jonathan can't remember any grand architectural justification for the = IANA restriction. At that time motivation was mainly SDP. However, see = no reason why we cannot reuse it for SIP.
  • Presenter: We're seeing non-SDP bodies for = which Warning might apply
  • Will not object. However, text for registry = document needs to be changed as well.

WG = chair asks the SIP WG to think generally about other uses of Warning if = we are expanding it to do this, and make sure all intended usages are = covered.

Conclusion: Ok to using Warning header (to describe issues with = bodies generally, but will need to change IANA registry text as = well.

Comment from floor outside scope of this slide on how some = intervening entity can know whether to pass on the contents on this or = not, and whether the server knows such an intervening entity exists. = Such hiding functionality is outside scope of current SIP work. = Assumption is that there is no value in interoperator diagnostics if = some hiding function provided at an edge.

Document currently uses Warning header 399, which implies no = automated action, but some comments have been made that automated = responses may be interesting.

Slide 4: Should a limit be = set on response size? Very large UDP responses may fragement so much = that no response reaches the request originator? Should that limit apply = to all responses? If yes, what size? There is no documented limit Scott = can find on response sizes (request sizes, but not responses). Do we = need a response to say my response is too big? Presenter would prefer to = duck this issue in this specific draft.

WG = chair indicated that until this problem is resolved in some manner, then = this draft will not progress.

Discussion:

  • We could trim off via's, etc. If UAC needs = them it can sip trace-route.
  • Presenter: Draft = allows exactly that to occur is so wish. Could also strip off mirrored = headers. Concern about not being reversable (NAPTR choices, = etc.).
  • But repeating the message does not ensure the same path. = Different path could create different error. Does not solve general = problem of response size.
  • Possible useful things in congestion-safety = draft
  • 3261 did not limit response size because at the time, the = responses were generally the same size as the requests, so the request = limit mostly limited the response. Put lower than MTU size on the = request, then hope the response did not grow beyond the MTU = size.
  • Presenter: Is this assumption still true. Many SIP assumptions = are not true any more.
  • need limit, much larger than request because = of Record-Route, etc. How to get fragments through NATs and = Firewalls.
  • Why not consider content redirection? Some = responses get quite large (488, etc.) - may not even want all this = stuff, let proxy store and diagnostics = retrieve?
  • Presenter: Is there a likelihood of = connecting HTTP seventy hops away?
  • If the response = gets fragmented, we could get retransmissions that may be worse than not = having the diagnostic info in first place. Not a completely useless = response if it tells you to stop = retransmitting.
  • Suggestion of a 200 byte limit for diagnostic = information. The request limit was chosen assuming that responses would = not usually add more than 200 bytes to request size. Last hop before UDP = to TCP will be at the size limit. Not an obvious answer on = this.

Conclusion: Document not ready for WGLC. Editor will introduce at = least two threads on issues raised in meeting. No objection to use of = Warning header. Message size must go to = list.

Connected Identity (draft-ietf-sip-connected-identity, = draft-elwell-sip-tispan-connected-identity)

Slides: sip-15.pdf

John Elwell presenting.

Slide 2: need for option-tag = to indicate UAS support for the identity header field in mid-dialog = requests? Saves UPDATE transaction after answer if the AoR is the same = as To header. However yet another option tag. Will anyone support = id-change without supporting connected-identity? Email suggestion to = make it dependent on receipt of id = header.

Proposal: Don't need new option = tag

Conclusion: Proposal = accepted =96 a new option tag will not be = provided.

Slide 3: sip-identity is = silent on how to behave if identity in "From" header field is not one = that authenticated UAC is allowed to assert. Left to local policy, but = this policy may be different for mid-dialog requests compared to initial = requests. Just add a note saying this?

Proposal: Add a note to indicate that it is effectively left to = local policy whether to reject or forward without identity = header.

Discussion:

  • reasonable but applies to Identity draft, = too, right?
  • blanket note in draft-ietf-sip-identity about = local policy, but isn't after every = paragraph.

Conclusion: Proposal to add note = accepted

Slide 4: Should we mandate = UPDATE for sending connected-identity rather than reINVITE. Could make = 3311 mandatory to support if you support id-change = tag.

Discussion:

  • what about implementations that don't do = update?
  • who can deal with identity should be able to do = update

Proposal: If you support this extention, you must support = UPDATE extension.

Conclusion: Accepted

Slide = 5: Should we mandate = inclusion of SDP offer in UPDATE request? Not strictly necessary. But = would be signed, in same way that SDP offer in INVITE request is = signed

Discussion:

  • Only useful if you mandate signed SDP. Up to = implementors, but implementors have to deal with the damage. Should call = sdp in update out as something you can do, but don't require = it.
  • just needs a way for this to be = possible

Conclusion: Not required. It needs to be optional. Allow this if = you wish, but do not require.

Slide = 6: Should To header = field URI in response be allowed to differ from the request? Body of = opinion that says that this is an entirely different consideration from = the one in Vancouver that led to decision to allow =46rom header field = URI to change in mid-dialog requests. No warning in RFC3261 that such a = relaxation might occur in the future (unlike the =46rom URI change). = Body of opinion that says it would not be useful. Body of opinion that = says it doesn=92t harm anything. TISPAN = requirements.

Leads into requirements from slide 7, = slide 8, slide 9, slide 10, slide 11, slide = 12 = (draft-elwell-sip-tispan-connectedidentity), = e.g. TISPAN needs two = identies each for caller and callee - one identity is used for billing, = the other is used for call-backs. For caller's identities, the proposal = is to use PAI (P-Asserted-Inentity) for billing-id, and "From" for = call-back-id. For callee's identities, the proposal is to use PAI for = one of ids, and there are a number of options for carrying the other = identity - To header, "From" of a new UPDATE request from callee to = caller, etc. Note written at same time as the identity coexistence draft = was put out, so conflicts could not be dealt with.

Discussion:

TISPAN = does not get to change what the

  • identity semantics mean without going through = sipchange process. The P-Asserted-ID has well defined values, and TISPAN = is trying to change that. TISPAN is not allowed to do = this.
  • Keith: Does not = redefine P-Asserted-ID - just says what will be put in = P-AID.
  • Interop problems with lots of people taking different views. If = each group redefines how identities are interpreted, nothing will = interoperate
  • TISPAN is just saying that the =46rom header = says who the caller thinks he is, P-AID is who the network things he is. = TISPAN thinks the different is useful.
  • PSTN does not know = the difference, only that P-AID is an authenticated = ID.
  • Using PAI for billing.
  • Have the understanding that PAI will be used = for callbacks as well. P-Asserted-ID must contain a reachable = AOR.
  • P-Asserted-ID has lost focus on what it means. Is being used by = enterprises. Hard to know which one to trust.
  • AD: Can we use something like = P-Charging-Vector to carry the billing. : This may imply we need a = billing ID. Could the 3gpp charging related headers be used? There are = real interop issues here on what to use for callback number and = caller-id presentation. May need discussion with liaison. May need to = spec a real charging vector. Not sure if he has captured the = problem.
  • Agrees with that = P-Asserted ID doesn't work as a charging vector. There are situations = where this make sense when you want to change the callback = number.
  • 3 = problems: who to bill, who to call back, what sort of subcategory of = user is the caller a part of.

Proposal: Does the editor fall back and specify requirements = around this in tispan-connected-identity? No. The proposed solution is = separable and could therefore be covered in another draft and therefore = it is separable from the connected identity = issue.

Conclusion: Connected identity will proceed without = this.

Further = discussions on the mailing list on the TISPAN = requirements.

Editorial question: Based on RFC 4485 requirement to show real = identities, do we need correct values for identity header field, along = with a real private key, etc. (as in = identity).

Cullen = Jennings: Please do this, hard to get this correctly and I'll do this = for you because it's hard. Still getting this nailed with Jon in AUTH48 = for draft-ietf-sip-identity, didn't have the same answer from two = separate implementations.

Security Flows = (draft-ietf-sip-sec-flows)

Slides: = sip-12.pdf

Robert = Sparks presenting.

Working = on creating examples with automated tool. Otherwise getting them right = is difficult.

Matching certificates rules aren't adequately captured; spread = out and not completely clear. This document is not normative, so they = will not be captured in this document.

WG chair asked if this fed into the security-guidelines draft = to be discussed later in the session.

AD: Should refer to 2818 rules as often as we can, but RFC = 2818 is informational, and this is already hitting drafts now. Will be = better when IESG gets the downref rules = completed.

Lots of = implementations match wildcards in DNS names, this is an education = issue.

On = finishing generation of examples, he will shortly submit a draft for = WGLC and publication.

Addressing the Forking Amplification Vulnerability = (draft-ietf-sip-fork-loop-fix)

Slides: sip-11.pdf

Robert Sparks presenting

Slide 2: Latest version demonstrates the attack with one resource and one = attacker, rather than multiple attackers. Reintroduces some of the = motivational text in the security consideration section (based on = conversations with Cullen). Updates the 3261 text on loop detection. = Identifies open issues. Added notes to implementers pointing to common = interop problems at earlier SIPits.

One Suggestion on mailing list not yet in draft: - Don't = start loop detection until you've gone around at least once =96 wait = until you see yourself earlier in the via stack. This is an optimisation = based on normally not going to hit this. Requires extra logic which = gives no major advantage.

Conclusion: WG agrees that this optimisation will not be = included in the draft.

Slide 3: In the computed = hash, why include all route values, callid, to-tag, from-tag, = proxy-require, proxy-authorization headers? Call id, to tag, from tag = don't need to be there as they are invariant. Proposal is to leave these = out.

- why = proxy require, proxy auith

Discussion:

  • we had reasons for all of these but not = written down and no one remembers why. Can think of Proxy-Require = justifications, but Proxy knows what header fields it would look at for = routing purposes on additional passes - does it = really?
  • Presenter: Normatively says anything you are using to compute = route goes in the hash=97would cover this = case.

Conclusion: Will leave items out of hash computation unless = something comes up in lists. Send specific issue to = list.

Feature Creeps - Advancing the SIP Standard - Documenting = the feature sets

Slides: sip-13.pdf

Robert Sparks presenting.

Task of = identifying the feature sets to advance the standard. Work is just = getting started. Want to avoid exponential explosion of must/should/may = features, so slide 2 contains an = example.

There = will brain-stroming on this topic in global.sipit.net. Wiki will be used = so anybody can participate. The expectation is to have an initial draft = by the San

Diego = meeting.

WG = chair: Please send out invitation to enable participation in this = effort.

Discussion:

  • Does progression effort make sense after = newtrk discussion.
  • Presenter: Other things motivate this work as = well. Building interoperability.
  • Need to make = strategic decision on whether a bug-fix doc should become a 3261bis = effort.
  • Presenter: Proposal on this coming out later. One motivation is = to determine what was stable and what was still = rough
  • Useful for feature compliance statements. "compliance to 3261" = must/may/should is absurd, need help here, there is value, whether we go = to draft or not.
  • Call flows more interesting for = implementors.

Hitchhiker's Guide = (draft-ietf-sip-hitchhikers-guide)

Slides: = sip-16.pdf

Jonathan Rosenberg presenting.

Adopted as WG item. Removed SIP family discussion of = specifications text; this is out of focus for the SIP WG itself. = Redefined what's in scope for the document (MIME usage specific to SIP = only, SDP stuff), Redefined what's a core spec =96 something that will = be used for every call. Added conferencing topic area, telephony specs, = minor extensions. Reference [42] is Hitchiker's Guide book, there's a = towel reference.

Issue: = When is document done? Proposal A: - Split core into a separate = document, issue immediately; rest of it goes much later. Proposal B: = Keep as one document, pick a point at which we decide to issue, revise = later on. Suggestion: Proposal B

Discussion:

  • keep together and = revise.
  • RFC 4510 all went out as one big chunk for LDAP, but maybe there = is experience here. Roadmap which says this is LDAP, but with this = document waited until all finished.
  • change the name? = need official-sounding name?
  • Presenter = disagrees, maybe people don't get the cultural reference but this is not = offensive.

Consensus on A or B will be determined on the = list.

Request for comments from editor.

SIPS: Guidelines = (draft-audet-sip-sips-guidelines)

Insufficient time for detailed discussion and will be discussed = further in the ad-hoc session to follow this = meeting.

However = WG chairs wanted to gain a view on the need for an informative document = to explain what we have and what we mean. Document will not contain any = normative changes, which would progress = separately.

Discussion:

  • More we dig under this rock, uglier the = problem becomes. We have a big problem, not sure we can fix = them.
  • AD: does anyone think there's NOT a problem? General derisive = laughter.
  • The more we get into this work, the more we = will realize what less we have got!
  • Francois Audet: = Third revision based on list discussion. Does not think we can fix this = without normative fixes. Does not believe anyone has successfully = implemented SIPS.

WG = chairs: Any objections to proceeding with an informative document? Will = ask ADs to add this to the charter.

There = was consensus to add this to the charter.

=A0

=A0

=A0

SIP Security Breakout

=A0

Issue Framing by Cullen = Jennings

We have = an interesting problem, based on list review, but there's a lot to look = at. Need to pick specific problems.

=A0

  • ICON for "secure phone call" - what does that mean? Some is = "local policy". Encrypted media? Know who you're talking to? Knowing the = person you dialed is the person who answered? Knowing no one snooped = your signaling? Some binding between all these things - this is what the = "hopping bunny" was about.
  • SIPS: URL does NOT = mean ANY of these things.
  • What ciphers are = acceptable?
  • Problems for SIP, AVT, = MMUSIC...
  • Problems on TLS and SIPS: - bugs and = unclarities, see Francois draft. May even have contradictions in specs, = need to resolve confusion. A ton of people have "implemented" TLS and = even SIPS: but not clear what works. "TLS across all the hops, or almost = all, or anything..." Hard to define, retargeting, ... SIP goes one = direction with retargeting, but SIPS: never thought about the other = direction. Have to decide what we want to do. Have to be symmetric. = "Secure" always TLS? See problems with = IPsec...

=A0

Discussion commenced = here.

=A0

Dean - = current document problem - no way to know that all nodes complied to the = spec in the middle.

=A0

Brian - = we either transitively trusting or we aren't. We have to = choose.

=A0

  • But we have requirements for end-to-end security, = too.
  • Can we assume transitive trust?
  • Jon - if there's a = SIPS URI that's signed, that's a comfort at the other end, but it's a = small comfort.
  • Can we agree on transitive = trust?
  • Simplifies scope but doesn't guarantee = solution.

=A0

Jon - = EKR suggested something like SIPS in the document (RFC 3261), and this = was late in the process, threat model pretty much worked out but SIPS = inserted quickly (too quickly? and carelessly). Probably a number of = problems to address.

draft-audet-sip-sips-guidelines-02

<= P class=3D"MsoNormal" style=3D"">=A0

  • "At best underspecified" and probably wrong. Started 00 to = explain how we were right ("we're the IETF"), and every version of the = draft gets worse.
  • Need to make some decisions pretty soon. = People are developing this now. Implementations don't have that much to = do with 3261.
  • Vijay - specific problems - = upgrade/downgrade, transport=3Dtls (deprecated). Can be implemented, but = there are problems.
  • Six sections in the draft - meaning of SIPS, = upgrading/downgrading, SIPS registration, SIPS dialog, transport=3Dtls, = a lot of other issues (GRUU, outbound, REFER, = background).
  • Meaning of SIPS - TLS for each hop until = terminating domain.
  • Jonathan - intent is that last link is secure = (somehow).
  • Biggest problem is that we're not symmetrical = for reverse path - in-dialog requests cannot = work.
  • Does not mean a Padlock icon, requires Record-Route or things get = dangerous quickly with SIPS Contacts.
  • Jon - issue was = assumption that UA would not be able to accept incoming TLS connections = - and assume that the reverse path would work the same way ("secure in = some sense").
  • "Support SIPS" is "support TLS connection to = remote first-hop proxy".
  • The part that's broken is that people assume = UAs don't have to support SIPS. They do, in order to make outgoing = calls.
  • Dean - Proxy is SIPS/SIP converter (in Dean's remembered = vision).
  • Record-Route and Contact interaction is not limited to = SIPS.
  • Jon - once we have outbound, we're in a position to do this = right.

=A0

Discussion of suggestions from list: deprecate SIPS altogether, = deprecate last-hop exception (not sufficient alone), explain the = exception and fix the bugs that result. Draft assumes third choice, but = lots of people like deprecating last-hop exception. People liked = deprecating SIPS, too... Noted that we need to accommodate 3GPP = here.

=A0

Do = people think we should deprecate SIPS? More chaos, people have = implemented SIPS. Juha said "broken for now" note until we fix it - = Francois' draft is that note :-)

=A0

  • Don't think SIPS works at all on a business card, or in to/from. = Can't use a padlock hop-by-hop.
  • What does = "deprecate" mean? Telling someone that SIPS will almost never = work?
  • EKR - point of SIPS is to provide given level of security. Does = it work? Problem is TLS ending at proxy.
  • Scott - "SIPS is = broken"? Want to be able to say a particular connection must be made = over TLS. Sometimes, that's the only thing that works. Need to be able = to say "secure" about particular hops.
  • Jonathan - we have many documents with "use = SIPS" as security considerations for relationships between proxies and = clients. That is reasonably useful, even if it's not end-to-end, even if = you need to trust middleboxes.
  • Francois - can't = deprecate, too pervasive.
  • What do we expect to get out of SIPS? Need to = know this to know if it's useful.
  • There is a real = threat being solved, preventing people snooping or modifying = requests.
  • This is everywhere in the document set. "Use = SIPS" is the "use IPSEC" of SIP.
  • Don't need to = change the meaning of SIPS in this group. Need to focus on the real = problems - last-hop, explanation Jon gave at beginning of the = meeting.
  • EKR - wouldn't it be great if we had end-to-end security, or even = integrity? In SIP, like it or not, trust model is that proxies can screw = you anyway they want. With that, SIPS is useful, but not for lock = displays.
  • Scott - agree with EKR, start by explaining = the meaning of SIPS. Clarify whether it's about signaling, and how far. = Doesn't cover media (which is what people actually think about, and a = totally different problem). I want TLS protection until I get to = something with the certificate that matches the request URI. I = understand semantics are different but think this needs to be clarified. = Francois has made a start at this.

=A0

Options = - deprecate SIPS, explain what SIPS means, allow = transport=3Dtls.

=A0

We = have consensus that we will not deprecate = SIPS.

=A0

Transport=3Dtls was formally deprecated, but no one believes this = and many/most implementations still understand and will use = this.

=A0

Allows = for "best effort" hop-by-hop TLS usage. Endpoints that cannot have a DNS = entry can't have own certificates = anyway.

=A0

(Also = need to add a transport=3Dtls-sctp (like Via) - would be more = consistent, too)

=A0

Jon is = confused here. how to start supporting TLS for one hop? But this isn't = about SIPS right now, right? We'll table this = now.

=A0

Registration issue:

=A0

  • Some people infer "must use TLS on REGISTER", etc. from current = documents.
  • Registration: AOR - SIP implies SIPS, this is = a big problem since many, if not all, UAs cannot process SIPS URIs. New = way to explicitly register SIP only?
  • If you only = register SIPS, you haven't registered SIP - this is not symmetrical, = either (more comfortable with upgrading than downgrading?) Is this = broken? Not sure why we're indicating that you have only one or the = other AOR...
  • Interaction with Outbound - create a TLS path = to home proxy, so proxy can send either SIP or SIPS to you over TLS ) = which is what you're asking for.
  • SIP and SIPS as = separate registrations? Cullen - this would always work. Can we imply an = upgrade path where one always implies the other? Which = way?
  • Francois - not backward compatible. If you send SIPS to most = clients you'll be in trouble. This is an AOR, right? It's equivalent to = being a different user. Or at least using a different = port.
  • Jon - great explanation by Jonathan but that's not in 3261 - = Jonathan agrees, this is the way to move forward. "URIs are never = equivalent" text does exist, but so does text that says both need to = exist as aliases.
  • Francois - some people are thinking you = should derive reachability from the transport you used for your = registration.
  • EKR - SIPS means "TLS all the way somewhere". = SIP means "maybe over TLS, maybe not", and can't expect people = downstream to use TLS or it may not work.
  • Does it matter = which AOR you use?
  • Jon - if you're registering a SIP URI, can't = expect you'll be able to do SIPS.
  • Francois - if you = don't use outbound, what does this mean?
  • Jon - use whatever = channel you've got.
  • Francois - was assuming the opposite (SIPS = would imply only SIPS, SIP would imply = both).
  • Registration contacts - list explicitly all valid transports, = using q-values?
  • Jonathan - clarifying 3261 without changing = it, right? Pointless. Let's start over and do this requiring SIP = outbound.
  • Jon - Outbound isn't done = yet.
  • Jonathan - This is done first?

=A0

Proposal - write a standards-track document that fixes 3261 and = requires outbound?

=A0

  • Keith - need to look closely at normative change process - do = guidelines document PLUS fixing 3261 = document.
  • Francois - need to agree on normative changes = - then we can split.
  • Aki - I like SIP in contacts, to, from. With = outbound, contact doesn't matter anyway. Don't put it in = to/from/contact.
  • Paul - when do we get clarification? No one = knows what it will take to fix this stuff (or at least not sure you're = talking about the same thing).
  • Francois - don't = pretend every statement in 3261 is correct.
  • Jonathan - we have = 200 bugs in Bugzilla - why would we question = this?
  • Jason - SIPS:transport=3Dtcp?
  • Robert - what does = that mean in a route header? TLS one hop = away?
  • Scott - back to the current definition of how many hops you use = TLS (until you reach the named destination = domain).
  • Jonathan - have proposed change to location lookup - add route = header. We screwed this up in 3261?
  • Scott - if you let = UA register SIPS URI with non-SIPS contact, that's an explicit action on = the part of the user.
  • Cullen - I think I agree = here.
  • How to deal with Contacts in REGISTER, Record-route, contact in = dialog...
  • Jon - hum on fixing 3261 instead of = apologizing?
  • Francois - thought we were making a proposal = to fix in next revision.

=A0

Next = steps - to list.

=A0

Jon - = need to know how this works with outbound in order to make = recommendations.

draft-gurbani-sip-sipsec-00.txt

=A0

Do SIPS = the way HTTPS works - end-to-end = upgrade?

=A0

  • EKR - HTTPS blows through proxies, "get out of my way". Not what = we're talking about now.
  • Cullen - if we didn't Record-Route, we'd get = the same thing in SIP.
  • Cullen - Dean arguing for something that only = works if there are no proxies. Interesting, scenario does = exist,=A0 but this isn't the = main case. This is why we don't encrypt = headers.
  • EKR - 18 proxies between point A and point B are there for a = reason, not just forwarding packets.
  • We'll talk about = this more on Friday afternoon (at P2P-SIP).
  • Vijay - we talked = about this on the list, and there are people who want their proxies to = stay involved.
  • Cullen - most of the proxy twiddlings are in = 3261 as threats, and the answer was "use end-to-end = security".
  • EKR - this creates a generic NAT traversal = server mechanism. Once you're in TLS, go crazy. There's like one proxy = between you and an HTTPS server.

=A0

=A0

draft-srivastava-sip-e2e-ciphersuites-00<= /SPAN>

Led by Samir Srivastava

Slides presented.

=A0

Principle argument: Level of security is missing. SIPS is a mess. = Should DTLS be considered as well?

=A0

Proposal: Extend Via to include Ciphersuites, define header for = desired cipher-suites, secure protocol, = etc.

=A0

  • EKR has an alternative solution - let TLS take care of = ciphersuites at each hop, rely on mandatory-to-implement as = common-denominator, trust proxies for mandatory = upgrade/downgrade.
  • Jonathan - with EKR on this one, proxies can = do so many things that are worse.
  • SS thinking of = catching evil proxies more quickly, allow UAC to control ciphersuite = selection.
  • SIP Security advisor says there's a hole in = this. Would Security ADs pass this = document?
  • EKR - current security is worse, = right?
  • Dean - this catches stupid proxies. Evil proxies = lie.
  • EKR - in TLS, your client has no control over what the server = actually chooses, right?
  • Proxies doing DTLS to TLS need to know = ciphersuites for other protocols.
  • Open issues - = which solution to pick? Partial adoption with SIPS? Impact of = renegotiation of ciphersuites needs to be = analyzed?
  • Has anyone else read the draft? 5 or 6. = Anyone who might implement?
  • John - I thought = so, not so sure now if we're trusting = proxies.
  • Dean - need a mechanism for Proxy A and Proxy C to keep an eye on = Proxy B - this could be it.
  • Discussions about = SIP and TLS don't state problems and then argue about details, so never = come to conclusions. Need starkly clear statement of problem and benefit = to users.

=A0

Conclusion: Please respin, focusing on problem = statement,=A0 = and we'll look at = this again.

=A0




= --Apple-Mail-4-244972171-- --===============0480607744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============0480607744==-- From sip-bounces@ietf.org Fri Aug 11 08:32:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWA2-0006Yl-NS; Fri, 11 Aug 2006 08:30:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWA1-0006Vg-05 for sip@ietf.org; Fri, 11 Aug 2006 08:30:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBW9z-0000pY-D2 for sip@ietf.org; Fri, 11 Aug 2006 08:30:44 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2006 05:30:43 -0700 X-IronPort-AV: i="4.08,114,1154934000"; d="scan'208"; a="335720670:sNHT34010024" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BCUgYT030722; Fri, 11 Aug 2006 05:30:42 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7BCUfuF006734; Fri, 11 Aug 2006 05:30:42 -0700 (PDT) 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, 11 Aug 2006 08:30:41 -0400 Received: from [10.86.243.41] ([10.86.243.41]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 08:30:41 -0400 Message-ID: <44DC786E.4060205@cisco.com> Date: Fri, 11 Aug 2006 08:30:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Jesus Javier Arauz (MI/EEM)" Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <33D71F0FC0684C4C8A3BB76989EDED9C024BCE71@eesmdmw020.eemea.ericsson.se> In-Reply-To: <33D71F0FC0684C4C8A3BB76989EDED9C024BCE71@eesmdmw020.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Aug 2006 12:30:41.0585 (UTC) FILETIME=[F57E3210:01C6BD41] DKIM-Signature: a=rsa-sha1; q=dns; l=5845; t=1155299442; x=1156163442; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Question=20regarding=20instance=20ID=20in=20GRUU=20and=2 0outbound; X=v=3Dcisco.com=3B=20h=3DOa/VNwPzdLqO79eqZZ6+DMJpgWI=3D; b=OdDaNmixrqfH/d9xx+iuWPB4px1TOCyFroA//AtpJXNtZ4LHQ07A+S9gGvJ54oVofRVyG3eM 3WLgayChdLvorFSXzuHM4NfuAuioZkMMrYEIfldWsZzNvpYzoFFonzCm; Authentication-Results: sj-dkim-8.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: sip , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jesus Javier Arauz (MI/EEM) wrote: > See inline. Regards, > /Javier > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: jueves, 10 de agosto de 2006 16:19 > To: Aki Niemi > Cc: sip > Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound > > > > Aki Niemi wrote: > >>> I also think its easier for a server to remember an instance ID to >>> GRUU binding for a long time, than it is for a client to remember its > >>> cookie for a long time AND for the server to remember the cookie to >>> GRUU mapping for a long time. GRUU persistence would depend on a >>> client remembering its cookie basically forever. GRUU currently >>> doesn't require persistent storage of any soft state in the client. >> Except it has to persistently store the instance-ID. When the UA moves > >> to another device, it supposedly needs to take the instance ID with > it? > > Well, that depends on whether you think it makes sense for a UA to move > to another device, or whether you thing UAs on different devices are > intrinsically different. > > I don't think there is a single answer to that - it seems to be a > religious issue. Some time ago I got into a debate about this with some > IMS folk, regarding how this should work on cell phones. > > I though the instance id ought to move around with the ISIM. > > Some others had very strong opinions that the instance id should be tied > to some id (I forget which one) that is tied to the body of the cell > phone rather than the ISIM. > > I gave up on that argument. It can be an individual choice by the maker > of the device and the software that runs on it. > > [Javier] The "id" you refer to above is the IMEI, which is sort of a > "serial number" that is assigned to each cell phone sold around the > globe. Generating the instance ID of a cell phone from its IMEI value > makes a lot of sense. The ISIM holds user-related information only, thus > that information alone cannot be used to generate an instance ID that > refers to the device where the ISIM is running. > That is orthogonal to whether the instance ID must change when a user > moves his ISIM around. The whole point of GRUU is to be able to reach a > specific user at a specific device, in most cases because it is known > that user is answering on that device. Hence if the user moves around > his ISIM the instance ID must change and he will get a new GRUU from the > registrar. I don't want to get deeply involved in a discussion of this because ultimately it is up to the implementor of the device to decide how it wants to do this. IMO the ISIM is the essence of the device, with the rest simply being peripherals that it uses. If I drop and break my cell phone, and move the ISIM to another one, *I* think that it should be considered to be the "same" *instance* for purposes of GRUU, presence, etc. But other reasonable people think otherwise. I'm satisfied to leave this to the discretion of the device implementor. Paul > In any case, it should often be the case that the instance id can be > derived from some piece of unchanging state that the UA has access to. > In such cases there is no need for the UA to take extra actions to save > it. > > There are cases when this isn't the true. The most obvious one to me is > when a soft phone is installed on a PC. There can be multiple softphones > potentially running concurrently on the same PC, but operating and > registering independently of one another. In such a case each one must > come up with a unique instance id. It may even be the case that the same > softphone installation can be used by different users on the PC, each > with a unique identity. In these cases there may be a need to explicitly > persist the instance id in a store that properly correlated with the > particular notion of "instance" that makes sense under the > circumstances. > > [Javier] IMHO the cases you mention are not a problem. In the first > case, since each softphone's UAS will be bound to its own TCP/UDP port > each softphone might receive different, unique GRUUs if the registrar > includes that port in the generated GRUU. In the second case, since each > user has his own AoR the GRUUs generated will be unique for each user if > the registrar includes the AoR in the GRUU. > A more complex situation arises when the same AoR is registered by > different users through the same shared softphone. In that case the > softphone must set the "grid" parameter to some value unique for each > user (it could be e.g. the user's login name or based on the user's > login password). > >> There's really no difference here to the (implicit) requirement on a >> UA that the UA has to store the user credentials, per AOR, in >> persistent storage, forever. >> > > [Javier] The UA does not need to store any user-related information, nor > does it need to use different information per AoR. It only needs a bit > of information it knows is unique and unchanging for the device the UA > is running on. The uniqueness characteristic might seem controversial > (i.e. how can it be guaranteed that some device manufactured next year > is not going to produce instance Ids that collide with IMEI or MAC > address values?) but if the URN concept is used properly there should > not be any collision. > >> Unless a blackphone intends to query a digest password upon every >> registration after a reboot cycle? That probably wouldn't work, >> especially with a numeric keypad and an alphanumeric password. Or at >> least I would toss that phone out the window pretty quickly. ;) > > The black phone can simply derive the instance id from its serial number > or some other convenient and unchanging piece of info. > > Paul > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 08:37:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWEm-0001wm-CK; Fri, 11 Aug 2006 08:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWEk-0001wh-TV for sip@ietf.org; Fri, 11 Aug 2006 08:35:38 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBWEj-00017X-9e for sip@ietf.org; Fri, 11 Aug 2006 08:35:38 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id C87C9199E7C for ; Fri, 11 Aug 2006 14:35:35 +0200 (CEST) Received: from [192.168.1.33] ([192.168.1.33]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 14:34:30 +0200 In-Reply-To: <200608111211.29581.ft@it.su.se> References: <8B1D53AEF7B03449A6D3771B3B7F850F029A5AFF@esebe103.NOE.Nokia.com> <200608111211.29581.ft@it.su.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 14:36:08 +0200 To: Fredrik Thulin X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 11 Aug 2006 12:34:30.0303 (UTC) FILETIME=[7DD1CAF0:01C6BD42] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My point exactly, I tried to say the same thing in an earlier email. Fredrik explained it better. Hisham On Aug 11, 2006, at 12:11 PM, Fredrik Thulin wrote: > On Friday 11 August 2006 10:48, Erkki.Koivusalo@nokia.com wrote: > ... >> 4. Can UA rely on the response from the proxy ? >> >> Fredrik Thulin >> >>> The argument that a response containing something saying >>> "I claim I can handle STUN requests you send me" is to be >>> trusted, but configuration saying ";keepalive=stun" is not >>> is flawed. >> >> Hadriel Kaplan >> >>> I would argue fairly vehemently that a server explicitly >>> indicating it supports something is far more reliable >>> than a UA believing the server supports something based >>> on a local config setting. >> >> Conclusion: >> - As this is hardcoded information in the proxy >> implementation, it is very probably reliable >> - It works in a similar way for Sec-Agree too > > I feel kind of misinterpreted here. My point was that no matter how > strong of an indication the UA receives that the first-hop proxy > supports STUN-in-SIP, it must still _verify_ that it does, and stop > sending STUN requests if the proxy in fact doesn't, even if it claims > it does. > > The proxy explicitly saying it supports STUN-in-SIP (through the > Proxy-Require scheme, or some other) is doubtlessly a strong indicator > but it doesn't _prove_ that the proxy supports STUN-in-SIP. > > This leads me to my opinion that just about any indicator at all the > UAC > has that the first-hop proxy supports STUN-in-SIP is a good enough > reason for the UAC to try and see if it actually does. I don't care > what the indicator looks like, but I don't want the Outbound draft to > be tied up in what I consider pointless discussions, and complex > solutions. > > I agree with those that wants to have _some_ kind of indicator of > support, but I think most people are overstating the importance of not > sending a few STUN-in-SIP packet to a proxy that doesn't support it. > Local configuration in the UAC is a good enough indicator for me. I > believe the blacklist argument to be FUD. > > /Fredrik > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 11 08:43:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWKt-0007Ma-WB; Fri, 11 Aug 2006 08:42:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWKs-0007MV-FW for sip@ietf.org; Fri, 11 Aug 2006 08:41:58 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBWKq-0001Zr-VK for sip@ietf.org; Fri, 11 Aug 2006 08:41:58 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id CCA6B19A557 for ; Fri, 11 Aug 2006 14:41:40 +0200 (CEST) Received: from [192.168.1.33] ([192.168.1.33]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 14:40:35 +0200 In-Reply-To: <200608111211.29581.ft@it.su.se> References: <8B1D53AEF7B03449A6D3771B3B7F850F029A5AFF@esebe103.NOE.Nokia.com> <200608111211.29581.ft@it.su.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1db7cafdb2bb50df419492c305e23e36@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 14:42:13 +0200 To: Fredrik Thulin X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 11 Aug 2006 12:40:35.0201 (UTC) FILETIME=[5750CF10:01C6BD43] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I also want to ask the people concerned why they are concerned. I can DoS your proxy with other things than STUN. Any binary junk will do. Worried about the extra unnecessary round trip for STUN? Thats not a good argument. Rohan's proposal requires the extra SIP roundtrip where the outboound proxy rejects the SIP request. A round trip of STUN is much cheaper than a roundtrip of SIP. Hisham On Aug 11, 2006, at 12:11 PM, Fredrik Thulin wrote: > On Friday 11 August 2006 10:48, Erkki.Koivusalo@nokia.com wrote: > ... >> 4. Can UA rely on the response from the proxy ? >> >> Fredrik Thulin >> >>> The argument that a response containing something saying >>> "I claim I can handle STUN requests you send me" is to be >>> trusted, but configuration saying ";keepalive=stun" is not >>> is flawed. >> >> Hadriel Kaplan >> >>> I would argue fairly vehemently that a server explicitly >>> indicating it supports something is far more reliable >>> than a UA believing the server supports something based >>> on a local config setting. >> >> Conclusion: >> - As this is hardcoded information in the proxy >> implementation, it is very probably reliable >> - It works in a similar way for Sec-Agree too > > I feel kind of misinterpreted here. My point was that no matter how > strong of an indication the UA receives that the first-hop proxy > supports STUN-in-SIP, it must still _verify_ that it does, and stop > sending STUN requests if the proxy in fact doesn't, even if it claims > it does. > > The proxy explicitly saying it supports STUN-in-SIP (through the > Proxy-Require scheme, or some other) is doubtlessly a strong indicator > but it doesn't _prove_ that the proxy supports STUN-in-SIP. > > This leads me to my opinion that just about any indicator at all the > UAC > has that the first-hop proxy supports STUN-in-SIP is a good enough > reason for the UAC to try and see if it actually does. I don't care > what the indicator looks like, but I don't want the Outbound draft to > be tied up in what I consider pointless discussions, and complex > solutions. > > I agree with those that wants to have _some_ kind of indicator of > support, but I think most people are overstating the importance of not > sending a few STUN-in-SIP packet to a proxy that doesn't support it. > Local configuration in the UAC is a good enough indicator for me. I > believe the blacklist argument to be FUD. > > /Fredrik > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 11 09:04:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWer-0005To-Rw; Fri, 11 Aug 2006 09:02:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBWeq-0005Tj-I2 for sip@ietf.org; Fri, 11 Aug 2006 09:02:36 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBWeo-0003vw-Ks for sip@ietf.org; Fri, 11 Aug 2006 09:02:36 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 959236E0001; Fri, 11 Aug 2006 15:02:31 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 15:02:31 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 15:02:30 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 15:02:30 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F132C@esealmw113.eemea.ericsson.se> In-Reply-To: <1db7cafdb2bb50df419492c305e23e36@telio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca9Q4+OBn7iixMmRfacc6TfSON4yAAAbpJg From: "Christer Holmberg \(JO/LMF\)" To: "Hisham Khartabil" , "Fredrik Thulin" X-OriginalArrivalTime: 11 Aug 2006 13:02:30.0929 (UTC) FILETIME=[678CF810:01C6BD46] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I am sure that there are cases where messages (STUN, or whatever) will be sent to destinations that don't support them, e.g. due to bad configuration. MY problem is that I don't like to standardize behavior which is based on sending something somewhere just to find out if the reciever supports the protocol in the first place. That is the reason I want to be able to get the information from the proxy before sending anything. Now, assume that case where the UA assumes (either via configuration or an indicator from the edge proxy) that the outbound proxy supports STUN, starts sending STUN requests but doesn't receive anything back. Of course it should stop sending STUN requests in that case. It's the same with SIP. If you send your request towards a proxy, but don't get anything back, sooner or later I assume you will stop sending your SIP request - even if you have been told (by configuration or something else) that the receiver supports SIP... Regards, Christer =20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: 11. elokuuta 2006 15:42 To: Fredrik Thulin Cc: sip@ietf.org; rohan@ekabal.com Subject: Re: [Sip] Outbound Issues: slides 3 and 4 I also want to ask the people concerned why they are concerned. I can DoS your proxy with other things than STUN. Any binary junk will do.=20 Worried about the extra unnecessary round trip for STUN? Thats not a good argument. Rohan's proposal requires the extra SIP roundtrip where the outboound proxy rejects the SIP request. A round trip of STUN is much cheaper than a roundtrip of SIP. Hisham On Aug 11, 2006, at 12:11 PM, Fredrik Thulin wrote: > On Friday 11 August 2006 10:48, Erkki.Koivusalo@nokia.com wrote: > ... >> 4. Can UA rely on the response from the proxy ? >> >> Fredrik Thulin >> >>> The argument that a response containing something saying "I claim I=20 >>> can handle STUN requests you send me" is to be trusted, but=20 >>> configuration saying ";keepalive=3Dstun" is not is flawed. >> >> Hadriel Kaplan >> >>> I would argue fairly vehemently that a server explicitly indicating=20 >>> it supports something is far more reliable than a UA believing the=20 >>> server supports something based on a local config setting. >> >> Conclusion: >> - As this is hardcoded information in the proxy >> implementation, it is very probably reliable >> - It works in a similar way for Sec-Agree too > > I feel kind of misinterpreted here. My point was that no matter how=20 > strong of an indication the UA receives that the first-hop proxy=20 > supports STUN-in-SIP, it must still _verify_ that it does, and stop=20 > sending STUN requests if the proxy in fact doesn't, even if it claims=20 > it does. > > The proxy explicitly saying it supports STUN-in-SIP (through the=20 > Proxy-Require scheme, or some other) is doubtlessly a strong indicator > but it doesn't _prove_ that the proxy supports STUN-in-SIP. > > This leads me to my opinion that just about any indicator at all the=20 > UAC has that the first-hop proxy supports STUN-in-SIP is a good enough > reason for the UAC to try and see if it actually does. I don't care=20 > what the indicator looks like, but I don't want the Outbound draft to=20 > be tied up in what I consider pointless discussions, and complex=20 > solutions. > > I agree with those that wants to have _some_ kind of indicator of=20 > support, but I think most people are overstating the importance of not > sending a few STUN-in-SIP packet to a proxy that doesn't support it. > Local configuration in the UAC is a good enough indicator for me. I=20 > believe the blacklist argument to be FUD. > > /Fredrik > > _______________________________________________ > Sip mailing list https://www1.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 > _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 11 09:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBXOy-0007PF-PY; Fri, 11 Aug 2006 09:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBXOw-0007PA-NM for sip@ietf.org; Fri, 11 Aug 2006 09:50:14 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBXOv-0001TM-OV for sip@ietf.org; Fri, 11 Aug 2006 09:50:14 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id E31C919F456 for ; Fri, 11 Aug 2006 15:50:11 +0200 (CEST) Received: from [192.168.1.33] ([192.168.1.33]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 15:49:06 +0200 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F132C@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F132C@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <02121a731098adcc1cfd384c487a3059@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 15:50:44 +0200 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 11 Aug 2006 13:49:06.0000 (UTC) FILETIME=[E98AF500:01C6BD4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: sip@ietf.org, rohan@ekabal.com, Fredrik Thulin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 11, 2006, at 3:02 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > I am sure that there are cases where messages (STUN, or whatever) will > be sent to destinations that don't support them, e.g. due to bad > configuration. > > MY problem is that I don't like to standardize behavior which is based > on sending something somewhere just to find out if the reciever > supports > the protocol in the first place. That is the reason I want to be able > to > get the information from the proxy before sending anything. Rohan's proposal is exactly what you dont want: sending something just to find out if the receiver supports the protocol. My opinion is that NOTHING should be mentioned in the internet draft about this at all. Its an implementation issue, imo, how a misconfigured UA should behave. Hisham > > Now, assume that case where the UA assumes (either via configuration or > an indicator from the edge proxy) that the outbound proxy supports > STUN, > starts sending STUN requests but doesn't receive anything back. Of > course it should stop sending STUN requests in that case. > > It's the same with SIP. If you send your request towards a proxy, but > don't get anything back, sooner or later I assume you will stop sending > your SIP request - even if you have been told (by configuration or > something else) that the receiver supports SIP... > > Regards, > > Christer > > > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: 11. elokuuta 2006 15:42 > To: Fredrik Thulin > Cc: sip@ietf.org; rohan@ekabal.com > Subject: Re: [Sip] Outbound Issues: slides 3 and 4 > > I also want to ask the people concerned why they are concerned. I can > DoS your proxy with other things than STUN. Any binary junk will do. > Worried about the extra unnecessary round trip for STUN? Thats not a > good argument. Rohan's proposal requires the extra SIP roundtrip where > the outboound proxy rejects the SIP request. A round trip of STUN is > much cheaper than a roundtrip of SIP. > > Hisham > > On Aug 11, 2006, at 12:11 PM, Fredrik Thulin wrote: > >> On Friday 11 August 2006 10:48, Erkki.Koivusalo@nokia.com wrote: >> ... >>> 4. Can UA rely on the response from the proxy ? >>> >>> Fredrik Thulin >>> >>>> The argument that a response containing something saying "I claim I >>>> can handle STUN requests you send me" is to be trusted, but >>>> configuration saying ";keepalive=stun" is not is flawed. >>> >>> Hadriel Kaplan >>> >>>> I would argue fairly vehemently that a server explicitly indicating >>>> it supports something is far more reliable than a UA believing the >>>> server supports something based on a local config setting. >>> >>> Conclusion: >>> - As this is hardcoded information in the proxy >>> implementation, it is very probably reliable >>> - It works in a similar way for Sec-Agree too >> >> I feel kind of misinterpreted here. My point was that no matter how >> strong of an indication the UA receives that the first-hop proxy >> supports STUN-in-SIP, it must still _verify_ that it does, and stop >> sending STUN requests if the proxy in fact doesn't, even if it claims >> it does. >> >> The proxy explicitly saying it supports STUN-in-SIP (through the >> Proxy-Require scheme, or some other) is doubtlessly a strong indicator > >> but it doesn't _prove_ that the proxy supports STUN-in-SIP. >> >> This leads me to my opinion that just about any indicator at all the >> UAC has that the first-hop proxy supports STUN-in-SIP is a good enough > >> reason for the UAC to try and see if it actually does. I don't care >> what the indicator looks like, but I don't want the Outbound draft to >> be tied up in what I consider pointless discussions, and complex >> solutions. >> >> I agree with those that wants to have _some_ kind of indicator of >> support, but I think most people are overstating the importance of not > >> sending a few STUN-in-SIP packet to a proxy that doesn't support it. >> Local configuration in the UAC is a good enough indicator for me. I >> believe the blacklist argument to be FUD. >> >> /Fredrik >> >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 11 10:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBXhN-0005BL-31; Fri, 11 Aug 2006 10:09:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBXhL-0005BF-5c for sip@ietf.org; Fri, 11 Aug 2006 10:09:15 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBXhI-0004lq-T9 for sip@ietf.org; Fri, 11 Aug 2006 10:09:15 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Aug 2006 07:09:12 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BE9CXY020404; Fri, 11 Aug 2006 07:09:12 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7BE9BVP009937; Fri, 11 Aug 2006 07:09:11 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-384.cisco.com [10.21.153.128]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7BE1NaG030044; Fri, 11 Aug 2006 07:01:23 -0700 Message-ID: <44DC8F87.9040507@cisco.com> Date: Fri, 11 Aug 2006 07:09:11 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=117; t=1155305352; x=1156169352; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:we're=20in=20a=20quagmire,=20so=20we=20can't=20leave; X=v=3Dcisco.com=3B=20h=3Djv+u1unqtsz57fn+ameoucIwpw4=3D; b=Lxp5uSW5q9S6JEXV5SuJJkcH7YIcEpG9zASVds7Ka17GWG2WmyzmyT9vSD3XHHGBFx47tkvf Fjt8eGu5o+jaG5kEYmOcmlLlJ78bnggzCh0m7bITrMs7A00zbMMTF4lc; X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: IETF SIP List , Cullen Jennings , Keith Drage Subject: [Sip] we're in a quagmire, so we can't leave X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > *We have consensus that we will not deprecate SIPS.* > Seems to be all the rage these days. Mike _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 12:36:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBZxu-0000nq-8q; Fri, 11 Aug 2006 12:34:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBZxt-0000lb-10 for sip@ietf.org; Fri, 11 Aug 2006 12:34:29 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBZxr-0001Vn-Nf for sip@ietf.org; Fri, 11 Aug 2006 12:34:29 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A192034C; Fri, 11 Aug 2006 12:34:26 -0400 From: "Hadriel Kaplan" To: "'Hisham Khartabil'" Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 12:34:26 -0400 Message-ID: <036a01c6bd64$02dac9b0$b7c8000a@acmepacket.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: <1db7cafdb2bb50df419492c305e23e36@telio.no> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca9Q4w+r8BidDrXT3qNiYC3mpveDgAGkj9g X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think I said why I'm concerned, but let me re-state. It is NOT because proxies won't be able to handle it. Despite the fact that history shows otherwise, I would hope proxies would do fine with binary junk. I do have a suspicion that some proxy or other won't, but that's probably good for my business. There is a question of what "fine" means, but that's a separate issue. (IMO, blacklisting is the right thing to do, but that's a decision for the vendor/operator) My primary concern is that the IETF is using a message, which does not conform to rfc3261/2543 syntax, to see if a rfc3261/2543 device supports this new syntax. That is wholly bad protocol practice, in my book. The SIP protocol has a mechanism to determine future-compatibility, but we're not using it. Why? It's not complicated, and doing this stun is really bad precedence. And the benefits of doing it the right way are that some 3261/2543 devices have logging mechanisms for the require check mechanism, so the operator can debug/troubleshoot it (or even learn such a draft exists). In terms of round-trips, Rohan's proxy-require method only adds one for negative results. A negative result for a stun message check is not 1 round-trip - it's not a round-trip at all - it's multiple stun messages from the UAC to the proxy. A negative result for a require check is 1 round trip. Is there a performance difference? I don't know; probably a nit. But round-trips are not my primary concern. Nor should they be for you, I would think. If the UAC's configuration is correct, and the proxy does support this, then there will be no round-trips. It's only if the UAC's config/discovery was wrong, and a round-trip is hardly a high price to pay for that case. The result of that require round-trip is an unambiguous negative acknowledgement that the proxy really doesn't support stun. Whereas a stun check negative is an implicit assumption that the proxy doesn't - it could very well be that the stun messages just got lost. A UAC would have a tough time figuring out the difference. I don't know if the UAC would behave differently, but making it ambiguous doesn't leave an option for this. -hadriel > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Friday, August 11, 2006 8:42 AM > To: Fredrik Thulin > Cc: sip@ietf.org; rohan@ekabal.com > Subject: Re: [Sip] Outbound Issues: slides 3 and 4 > > I also want to ask the people concerned why they are concerned. I can > DoS your proxy with other things than STUN. Any binary junk will do. > Worried about the extra unnecessary round trip for STUN? Thats not a > good argument. Rohan's proposal requires the extra SIP roundtrip where > the outboound proxy rejects the SIP request. A round trip of STUN is > much cheaper than a roundtrip of SIP. > > Hisham _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 13:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBaPo-0005z0-8B; Fri, 11 Aug 2006 13:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBaPn-0005yv-Hz for sip@ietf.org; Fri, 11 Aug 2006 13:03:19 -0400 Received: from jes-fe2.zx.nl ([194.187.76.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBaPm-0003hR-8x for sip@ietf.org; Fri, 11 Aug 2006 13:03:19 -0400 Received: from Inbox ([89.205.131.57]) by jes-fe2.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J3U00FTVICCA220@jes-fe2.zx.nl> for sip@ietf.org; Fri, 11 Aug 2006 19:07:52 +0100 (WEST) Date: Fri, 11 Aug 2006 19:03:23 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] Outbound Issues: slides 3 and 4 To: Hisham Khartabil , "Christer Holmberg (JO/LMF)" Message-id: <0J3U00FTWICEA220@jes-fe2.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, rohan@ekabal.com, Fredrik Thulin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan's proposal is exactly what you dont want: sending something just=20 to find out if the receiver supports the protocol. [jvb] What he means is sending something that is not SIP, Rohan's proposal = is pure SIP My opinion is that NOTHING should be mentioned in the internet draft=20 about this at all. Its an implementation issue, imo, how a=20 misconfigured UA should behave. [jvb] This discussion is about defining what it means for a UA to be compli= ant, not about misconfigured UAs. The rule should be that a UA does not STU= N unless it is "reasonably" sure that the other side supports it. A checkbo= x marked by the user is not reasonable. Some people argue that discovered '= ;keep-alive=3Dstun' is reasonable. An indication from the element itself is= at least more reliable than the former, but nothing is 100%.=20 [jvb] Given that the indication from the target can be obtained relatively = cheaply by piggybacking on existing signalling, IMHO that SHOULD be the nor= m Regards, Jeroen _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 13:14:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBaYc-0006Et-Qr; Fri, 11 Aug 2006 13:12:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBaYb-0006Eo-S4 for sip@ietf.org; Fri, 11 Aug 2006 13:12:25 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBaYa-0004OH-Ke for sip@ietf.org; Fri, 11 Aug 2006 13:12:25 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id AA770178; Fri, 11 Aug 2006 13:12:23 -0400 From: "Hadriel Kaplan" To: "'Hisham Khartabil'" Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 13:12:23 -0400 Message-ID: <036e01c6bd69$50133690$b7c8000a@acmepacket.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: <02121a731098adcc1cfd384c487a3059@telio.no> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca9TSqDt/TxK0DHT3aiowEa55Hz7wAFv9yA X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > > Rohan's proposal is exactly what you dont want: sending something just > to find out if the receiver supports the protocol. On the contrary, Rohan's proposal uses the base protocol to find out if a new protocol is supported. That's a big difference from just trying the new protocol and seeing what happens. RFC 3261 has a defined syntax to discover if the 3261-compliant device supports something new, if it must support the new thing for it to work properly. That is exactly the case here. We require the proxy to support stun. Why do we have Supported, Accept and Allow headers? Just try whatever it is and see if it works. (not exactly analogous, but you get the idea) Don't get me wrong - I want to be VERY conservative with using proxy-require and require headers. But if anything qualifies for it, this case does IMO. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 13:38:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBawT-0002IB-Ch; Fri, 11 Aug 2006 13:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBawS-0002I5-1T for sip@ietf.org; Fri, 11 Aug 2006 13:37:04 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBawP-0007Gx-P0 for sip@ietf.org; Fri, 11 Aug 2006 13:37:04 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A03101C0; Fri, 11 Aug 2006 13:36:49 -0400 From: "Hadriel Kaplan" To: "'Fredrik Thulin'" , Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 13:36:48 -0400 Message-ID: <036f01c6bd6c$b9cdfcc0$b7c8000a@acmepacket.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: <200608111211.29581.ft@it.su.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca9Lr8qagqGVJRjSxGQ4ykUM8/DBwAOqCNA X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se] > I don't care > what the indicator looks like, but I don't want the Outbound draft to > be tied up in what I consider pointless discussions, and complex > solutions. I don't understand how a proxy-require option tag is considered complex, when one has to implement the other changes in this draft. I have a very strong suspicion the coding, testing, and documentation for it would take less text and time than the emails generated thus far about it. :) -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 16:29:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBdbh-0001BY-KD; Fri, 11 Aug 2006 16:27:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBd8K-0000A9-S3 for sip@ietf.org; Fri, 11 Aug 2006 15:57:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBYiv-0005ey-8X for sip@ietf.org; Fri, 11 Aug 2006 11:14:57 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBYEX-0007s7-MR for sip@ietf.org; Fri, 11 Aug 2006 10:43:36 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20060811144330m1300lakp6e>; Fri, 11 Aug 2006 14:43:30 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k7BEhTeY032177 for ; Fri, 11 Aug 2006 10:43:29 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k7BEhTel032173; Fri, 11 Aug 2006 10:43:29 -0400 Date: Fri, 11 Aug 2006 10:43:29 -0400 Message-Id: <200608111443.k7BEhTel032173@dragon.ariadne.com> From: Dale Worley To: sip@ietf.org In-reply-to: <44DB8038.5080903@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <44DA550E.9020602@cisco.com> <1155216398.7999.58.camel@macbuster.research.nokia.com> <6B49F320-181F-4560-939C-A9822000E89E@softarmor.com> <44DB8038.5080903@cisco.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Fri, 11 Aug 2006 16:27:48 -0400 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Paul Kyzivat > Or does this error simply result in any messages to the "old" GRUU being > lost or misrouted, and thereby hurt nobody but the user of the > misbehaving UA? It *can* be implemented so as to behave as you describe in the last paragraph above. Speaking as someone who as actually implemented GRUU support (in the sipX open-source proxy, http://www.sipfoundry.org), it is all quite easy in practice: At registration time, the registrar hashes the AOR and instance ID (with a key-string) to generate the GRUU. This assures that an AOR/instance pair always generates the same GRUU. To provide reverse mapping from the GRUU to the contact, the GRUU is stored in the database record that holds the registration. This is a bit more storage, but the registrar already contains a database table of registrations, so it's not much programming work. Of course, if a UA decides to use different instance IDs over time, it gets different GRUUs, but that only interferes with its own operation. The database records for the additional GRUUs are automatically garbage collected when the registrations that created them time our or are superseded. Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 11 17:15:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBeK9-0005xf-Te; Fri, 11 Aug 2006 17:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBeK8-0005wv-8o for sip@ietf.org; Fri, 11 Aug 2006 17:13:44 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBeK5-0005NZ-Td for sip@ietf.org; Fri, 11 Aug 2006 17:13:44 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7BLDcV17979 for ; Fri, 11 Aug 2006 17:13:38 -0400 (EDT) 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 Subject: RE: [Sip] we're in a quagmire, so we can't leave Date: Fri, 11 Aug 2006 16:13:36 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DC6A533@zrc2hxm2.corp.nortel.com> In-Reply-To: <44DC8F87.9040507@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] we're in a quagmire, so we can't leave Thread-Index: Aca9UPT4fs8giTr7QgGJkh89AN3jywAOdPZQ From: "Samir Srivastava" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My rumble (which I was not allowed to say earlier) This is the price of early adapters who implemented without considerations, which others who are implementing with analysis are agreeing to pay.=20 =20 IMHO, It's a result of series of mistakes, and we are going to do one more instead of doing the surgery. When SIP entities can be upgraded with other extensions, why not with this ? If DTLS needs to be adopted, with SIPS then following from 19.1.1 of 3261 needs to changed too... "For a SIPS URI, the transport parameter MUST indicate a reliable transport." There was a argument that we have SIPS referenced so many places how can we do it? We have 3261 referenced at so many places, which has bugs too. This is another bug... Where are those protocol purists who killed PING because of Proxy-Require, and at that time there were other keep alive implementers too? Thx Samir PS: I am enjoying my deep breaths and I will be no more vocal on this. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, August 11, 2006 7:09 AM > To: Dean Willis > Cc: IETF SIP List; Cullen Jennings; Keith Drage > Subject: [Sip] we're in a quagmire, so we can't leave >=20 >=20 > > > > *We have consensus that we will not deprecate SIPS.* > > > Seems to be all the rage these days. >=20 > Mike >=20 > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Sat Aug 12 00:58:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBlYX-000055-KJ; Sat, 12 Aug 2006 00:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBlYW-0008Sx-99 for sip@ietf.org; Sat, 12 Aug 2006 00:57:04 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBlYV-0001iW-0c for sip@ietf.org; Sat, 12 Aug 2006 00:57:04 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 11 Aug 2006 21:57:02 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7C4v2im018673; Fri, 11 Aug 2006 21:57:02 -0700 Received: from [192.168.1.2] (sjc-vpn-hwcore-263.cisco.com [10.21.153.7]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7C4v2uD006622; Fri, 11 Aug 2006 21:57:02 -0700 (PDT) In-Reply-To: <200608100302.k7A32ks7013575@dragon.ariadne.com> References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <3135FE06-4196-44A4-9310-0AFEF22E449D@cisco.com> <200608100302.k7A32ks7013575@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1550C521-0148-4C7D-8675-AAFC27A84235@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound Date: Fri, 11 Aug 2006 21:56:54 -0700 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=658; t=1155358622; x=1156222622; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Question=20regarding=20instance=20ID=20in=20GRUU=20and=2 0outbound; X=v=3Dcisco.com=3B=20h=3DIENY9UeXpCdBpVOdSBMqVoWwwaY=3D; b=cDA/vNyIxaLH+i/Z81lMQRXdSb2ND9YiMRbowYf/EgQpKOS3cHsYdcD4iXas2xCXs25OEPPq rY2OWbM+Fnzv5E40LNnA9QHlfphzRH2EdwI8XVDTvaxNH0NFc3uLrVaY; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 8:02 PM, Dale.Worley@comcast.net wrote: > Let me suggest that the current concept (a URN as an instance ID) is > (from the point of view of the protocol) as simple as UUIDs, but more > general, and covers cases that UUIDs cannot: > > - If you have a MAC address, you can package that into a UUID, which > can be made into a URN. > > - If you choose a big random number, you can package that into a UUID, > which can be made into a URN. > > - If you want delegated assignment, you can assign an OID, which can > be made into a URN. > Yes, I agree - but do we have a use case where someone wants to use an OID? _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 01:16:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBlq1-0005gG-Px; Sat, 12 Aug 2006 01:15:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBlq0-0005fo-EF for sip@ietf.org; Sat, 12 Aug 2006 01:15:08 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBlcW-0001xE-Im for sip@ietf.org; Sat, 12 Aug 2006 01:01:13 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2006 22:01:12 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7C51BV7019309; Fri, 11 Aug 2006 22:01:11 -0700 Received: from [192.168.1.2] (sjc-vpn-hwcore-263.cisco.com [10.21.153.7]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7C51BIZ001415; Fri, 11 Aug 2006 22:01:11 -0700 (PDT) In-Reply-To: <44DACA71.8030601@softarmor.com> References: <5EB80D22825EEE42872083AD5BFFB594017F12F7@esealmw113.eemea.ericsson.se> <836b512099bc8be1f49ca0fc417e7ddf@ekabal.com> <44DACA71.8030601@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 22:01:04 -0700 To: Dean Willis X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=198; t=1155358871; x=1156222871; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=feg0y/rFgb19/TOzdlwbEwd1SjlCvnSii+tbBtU8rnpNR6Z/fdE6AeDt4eLVT+HYXZU2CIgw Nq4JCfXh86NBTxNMV8hEMb+6mfSg2hKf7LPYVpJDsQY6Z6LyXgegFa63; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 9, 2006, at 10:56 PM, Dean Willis wrote: > Bad Hisham! No biscuit! None for me either! It's not a biscuit - we have cookies around here. Oops now I am off topic too - bad fluffy. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 01:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBlqR-0006F3-5h; Sat, 12 Aug 2006 01:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBlpv-0005dR-BH for sip@ietf.org; Sat, 12 Aug 2006 01:15:03 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBlnN-0002J0-1C for sip@ietf.org; Sat, 12 Aug 2006 01:12:26 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 11 Aug 2006 22:12:24 -0700 X-IronPort-AV: i="4.08,116,1154934000"; d="scan'208"; a="1846428745:sNHT32443612" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7C5CObK006279; Fri, 11 Aug 2006 22:12:24 -0700 Received: from [192.168.1.2] (sjc-vpn-hwcore-263.cisco.com [10.21.153.7]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7C5CNuD009420; Fri, 11 Aug 2006 22:12:23 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F132C@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F132C@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <792A45F8-C20F-4113-9F1E-458F0702F2D6@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 22:12:16 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=625; t=1155359544; x=1156223544; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=ZrEYWtHdTZ+QMwUVayl519Ge4prrGQQuLjrYWbIQ2A7Tf9i4ecrOkaMTp8Qu+U26KWepkEgI UO+VZhHYcgfKXZv6/7RPriV9p0XtPTlCnCYfr4sHjGwtXQZ3cMbDqyon; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org, Fredrik Thulin , rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 11, 2006, at 6:02 AM, Christer Holmberg ((JO/LMF)) wrote: > MY problem is that I don't like to standardize behavior which is based > on sending something somewhere just to find out if the reciever > supports > the protocol in the first place. I will point out that when a UA is configured to send requests to sip:example.com:5060 the way we find out if that port on that machine supports SIP is by sending a SIP request to it. I'm not sure I fully grasp the difference here. However, have you thought about Bob's proposal - it seems like it might be the thing that everyone can live with. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 01:17:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBlqj-00073p-UJ; Sat, 12 Aug 2006 01:15:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBlpw-0005dR-1G for sip@ietf.org; Sat, 12 Aug 2006 01:15:04 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBllI-0002Gb-CU for sip@ietf.org; Sat, 12 Aug 2006 01:10:17 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 11 Aug 2006 22:10:16 -0700 X-IronPort-AV: i="4.08,116,1154934000"; d="scan'208"; a="1846428647:sNHT30884522" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7C5AFgj028563; Fri, 11 Aug 2006 22:10:15 -0700 Received: from [192.168.1.2] (sjc-vpn-hwcore-263.cisco.com [10.21.153.7]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7C5AEuD009200; Fri, 11 Aug 2006 22:10:15 -0700 (PDT) In-Reply-To: <036f01c6bd6c$b9cdfcc0$b7c8000a@acmepacket.com> References: <036f01c6bd6c$b9cdfcc0$b7c8000a@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 22:10:07 -0700 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=489; t=1155359415; x=1156223415; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=m049iT0QaEZ48uktGK9YkVE1W3zwQjFVxMk/EO0RQiYseYEcRgpwOckdsa8+DGF1JylpRpNS Q1J0fByRy06LY2HcTphodzhovOfUsjtJ7EmLdFIDWeNXBmN1UCWMf3RE; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: SIP , Fredrik Thulin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 11, 2006, at 10:36 AM, Hadriel Kaplan wrote: > I don't understand how a proxy-require option tag is considered > complex, > when one has to implement the other changes in this draft. The problem is not the proxy-require. The problem is the proxy removing things from the proxy-require header. Have you considered the solution that Bob proposed for this. It did not have this problem of modifying the proxy require and it seem to solve all of your concerns. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 01:49:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBmLw-0000Cy-Fp; Sat, 12 Aug 2006 01:48:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBmLu-0000Ct-Mm for sip@ietf.org; Sat, 12 Aug 2006 01:48:06 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBmLs-0005gM-QI for sip@ietf.org; Sat, 12 Aug 2006 01:48:06 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 11 Aug 2006 22:48:05 -0700 X-IronPort-AV: i="4.08,116,1154934000"; d="scan'208"; a="1846431376:sNHT38295434" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7C5m4TV026738; Fri, 11 Aug 2006 22:48:04 -0700 Received: from [192.168.1.2] (sjc-vpn-hwcore-263.cisco.com [10.21.153.7]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7C5m3IZ008032; Fri, 11 Aug 2006 22:48:03 -0700 (PDT) In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F029A5AFF@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F029A5AFF@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E8AC79A-EA67-40BA-82BA-9922B5EE43CC@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Fri, 11 Aug 2006 22:47:54 -0700 To: "" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=16554; t=1155361684; x=1156225684; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204=20; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=BlZuVRWxyB3PixGa0UcAyeZYku2E3SNZpM65iFPA9BtZRkmsFuaIfGeGWPuT0manlusFDgB+ RhkRjcIGwCJX4BvQnfvnIwcYJHUHdx8ySF+cjUFiimw72kTnM0AEnn9L; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org More inline but my meta level comment is, would the proposal Bob was talking about solve all the things you bring up here - I suspect it would. On Aug 11, 2006, at 1:48 AM, wrote: > > Hi, > >> We had a very long discussion in Montreal about discovery and >> validation of a SIP outbound proxy server's ability to receive STUN >> requests. While the vast majority of the room was comfortable that >> "keepalive=stun" in a URI was a sufficient indicator that an outbound >> proxy supports SIP and STUN over the same port, a small but extremely >> vocal minority had significant problems with this assumption. > >> Concern that the mailing list combatants on these issues are not >> present in the room; this will have to go to the mailing list. > > Being one of those "extremely vocal combatants not present in > Montreal" > it is now time for myself to express my opinion about proposed > solutions > and the related discussions I could recap from the IETF SIP WG meeting > minutes and the emails on this subject prior to and after the meeting. > > First of all I was very delighted to see that one of the authors > of SIP Outbound finally took this issue up and proposed a solution > for it, to be added to the Outbound draft: > >> I am willing to try a validation proposal which >> adds no extra round trips if the SIP UA was indeed correctly >> configured. >> >> The specific proposal works like this. A UAC which has an >> outbound URI indicating with ;keepalive=stun that the next >> hop can support STUN messages on the SIP port, needs to verify >> the first hop supports STUN before sending any STUN messages. >> The UAC sends its first SIP message to the next hop with a > Proxy-Require: sip-stun. If the URI was correct >> (STUN was supported), and the first-hop is an intermediary, the >> first-hop removes the Proxy-Require and forwards the SIP request >> (probably a REGISTER request) along adding no additional delay. A >> positive response to a REGISTER or OPTIONS with Supported: >> outbound and no error counts as positive confirmation that either >> the registrar supports STUN or expects to never receive a request >> without getting it from an outbound proxy which did not complain >> about the Proxy-Require [1]. If the UAC was misconfigured >> (the first-hop intermediary does not support STUN keepalives), >> either the first hop will reject the SIP request (if it is an >> intermediary), or the registrar will not include >> an indicator that it supports outbound (if the first hop was the >> registrar). > > I find this solution perfect: it is simple, complete, lightweight, > proven to work in other contexts, it solves the problem neatly. > I would say: "Just do it and let the Outbound draft converge". > > But it seems to be not that easy after all. Let me recap the > current situation with this proposal. > >> From the raw WG notes and emails about the subject after the > meeting I was able to gather the following summary for this > proposal. Please tell if I have misinterpreted your statement > in the mailing list and counted you into a wrong camp: > Hmm, I think when you add in the people that gave their opinion in the WG meeting you add a few people who thought the draft need to be changed and a very large number of people who would rather see up leave the draft as is so we could get it done. > A. GO: > > 10 WG members have expressed that they understand the > Proxy-Require solution and do not see a problem > with it: > > Rohan Mahy > Robert Sparks > Hadriel Kaplan > Jeroen van Bemmel > Bob Penfield > Christer Holmberg > Francois Audet > Joel M. Halpern > Dean Willis > Erkki Koivusalo > > B. No-GO > > 4 WG members are opposing the Proxy-Require solution > > Cullen Jennings > Jonathan Rosenberg > Hisham Khartabil > Fredrik Thulin > > I would like to revisit the issues explicitely mentioned > in the mailing list against the Proxy-Require solution > and my conclusions for each of those issues. Sorry that > this becomes long story, but I just could not help it: > > > 1. Is there a real problem to be solved ? > > Cullen Jennings >> Just so we are clear on the when this could be a problem.... >> >> For any UA that is automatically configured, this is unlikely to >> every be a problem. What we are talking about here is UA where some >> human types in the configuration information to the UA. Even though >> they were told to enter example.com as the outbound proxy, they >> decide to enter example.com;keep-alice=stun because perhaps they saw >> in some other system. > > Please note that user possibly does not need to type > the ;keep-alive=stun. The UA might have a user interface > with one button with text "Is the phone behind a NAT ?" > and after selecting "Yes" the phone would add this URI > parameter. Perhaps badly designed UA, but possible. This was mention at at least two IETF meetings now and every time I have requested, as I will ask you now, please send text to add to the draft that tell UA implementors not to do that. I'm sure this sort of text would improve the draft. > > Christer Holmberg: >> Assuming the UA is configured with a URI, yes. But, in case the >> UA only gets the IP address of the proxy, you still have a problem. > > Jonathan Rosenberg: >> 1. a user types in their outbound proxy and adds keepalive=stun when >> they shouldn't have >> 2. outbound proxy is discovered via DHCP, and since DHCP provides a >> hostname and not a URI, a UA constructs a URI, and since it supports > the >> stun keepalive adds the parameter >> >> Case #2 is a legitimate cause for concern. > > Conclusion: it is a problem because of the following reasons: > - UA might only have the IP address of the proxy available > - UA might get the domain name from DHCP without URI params > - UA might be configured by the user incorrectly Bob's proposal nicely deals with all these issues. > > > 2. Is the solution in scope of SIP Outbound draft ? > > Cullen Jennings: >> I think this is out of scope of this draft. > > Jonathan Rosenberg: >> I agree its out of scope. >> >> However if we had a mechanism >> for autodiscovery of outbound proxies, where a URI was provided by >> that > >> proxy itself, then this use case goes away, and the need for some of >> these verification mechanisms goes away too. >> >> So, I had proposed at the mike during ietf a mechanism for discovery >> using Service-Route (Path is the wrong direction), which would make > sure >> that, even if a client discovers the proxy initially via DHCP, it >> quickly learns a URI from that proxy which would inform it about > whether >> stun is supported. Draft coming soon on this... >> >> If we had such a mechanism, then I dont think we need any of this >> mess. > >> Since we need a proper discovery mechanism regardless lets solve that >> problem and ditch the extra mechanism. > > Christer Holmberg: >> Anyway, if you DO agree that it's relevant we don't need >> to argue whether it's in the scope or not :) > > Dean Willis: >> There have been several options mentioned to do this, a simple >> way is to have the edge proxy insert a flag. Question is: why not? >> >> I find that I've developed a great deal of sympathy for the above >> position. Discovery is indeed separable from error-detection (or >> confirmation, detecting "absence of error"). > > Conclusion: > - Since this draft creates such a problem it is in my > understanding in the scope of this draft to fix it, > expecially when the means are already outlined and > seem to be well understood and widely accepted. > - Moving the solution to another draft would mean that > we introduce the problem to the market when the draft > is approved as RFC but would postpone solving it to > some undetermined date (if ever). > > > 3. Does Proxy-Require technique work or is it too complex ? > > Jonathan Rosenberg: >> In particular, though I dont really see a lot of harm in Rohans >> Proxy-Require proposal, I think its unnecessary complexity if >> you have a proper discovery mechanim. > > Is the proposal really so complex at all ? I propose > the following text for the Outbound draft: > > The UA SHOULD add a Proxy-Require header field with the > value "sip-stun" to its REGISTER request. When the UA > receives 200 OK with Supported: Outbound it can be sure > that the next hop will support STUN keepalives. > > The proxy MUST remove the "sip-stun" value from the > Proxy-Require header field and then remove the header > if no values remain before forwarding the request to > the next hop. > > If you have any doubts whether it works or not, please > look into RFC 3329 from which I copied this text and > modified it to sip-stun purpose. It is proven and widely > deployed technique within Sec-Agree. > > Dean Willis: >> The only thing I have seen in Rohan's proposal that makes people >> queazy is the handling of the proxy-require -- that is, removing >> it in the first hop proxy. >> >> To quote a few IETF's back, "That doesn't bother me at all". >> >> But it seems to bother Cullen and a few others, even if I did >> borrow his words to say I'm ok with it. > > Conclusion: > - As Proxy-Require is used in a similar way in RFC 3329 > with wide deployment this concern can be ignored. I don't think this is the same deployment model as sec-agree and I don't think sec-agree works as well as you think it works. I think I outlined issues with this before so won't rehash. Various people have expressed concern that allowing deletion of things from proxy-require would make it harder to add in upward negotiation of security features. Now in an IMS system, sec-agree provides some alternative to do this so it mitigates the issue by providing an alternative way to accomplish some of the stuff that is lost when using it. The proposal here does not. > > > 4. Can UA rely on the response from the proxy ? > > Fredrik Thulin >> The argument that a response containing something saying >> "I claim I can handle STUN requests you send me" is to be >> trusted, but configuration saying ";keepalive=stun" is not >> is flawed. > > Hadriel Kaplan >> I would argue fairly vehemently that a server explicitly >> indicating it supports something is far more reliable >> than a UA believing the server supports something based >> on a local config setting. > > Conclusion: > - As this is hardcoded information in the proxy > implementation, it is very probably reliable > - It works in a similar way for Sec-Agree too > > > 5. What if there is no proxy between UA and registrar ? > > Rohan Mahy: >>> Francois: Are you worried that such a REGISTRAR may not believe >>> the Proxy-Require was intended for itself? >> >> Exactly. Proxy-Require is generally supposed to be ignored by UAs. > > Conclusion: > - Not a problem since in this situation the UA can > infer from Supported: Outbound header of 200 OK > that the registrar also supports STUN keepalives. > Just like outlined in Rohan's proposal. > > > 6. Mandating UA not to send STUN packets before it has > sent a REGISTER with Proxy-Require towards the proxy ? > > Hisham Khartabil: >> I don't like this proposal. I'm still with the camp that says: if >> configured, then it must be true. >> >> My main objection is that in this proposal, you are required to send >> SIP messages before STUN messages. That's a mandate that I'm not >> comfortable with since I might want to send STUN first to discover my >> public IP/port to populate the contact header before I send the first >> REGISTER. > > Jonathan Rosenberg: >> Hisham - why would you want to do this? The whole idea of sip- >> outbound >> is to make the IP in the Contact irrelevant. It will be ignored >> anyway. > >> Perhaps you are worried about an outbound proxy that supports stun >> but > a >> registrar that doesn't support sip-outbound? >> >> There are some pretty sizeable security risks in doing this. > > Conclusion: > - Jonathan already rejected the idea Hisham had > - On the other hand it is possible to specify that the > UA either SHOULD or MAY add Proxy-Require, instead of > mandating it, if this is still regarded as a problem > > > 7. Is there any better solution available so that > Proxy-Require would not be needed ? > > 7.1 Sending OPTIONS before REGISTER > > Cullen Jennings: >> How about if we said something like >> >> If the UA did not learn the outbound proxy set thru auto-config or >> discovery mechanisms, then it MUST do an OPTIONS message first and >> check for a sip-stun option tag. (clearly more wording needed but you >> know what I mean) >> >> Would that work for you? I suspect it would work for most people. I'd >> certainly be in favor of that. > > Cullen Jennings >> For these reasons, I don't think this whole problem is not a huge >> deal. However, if people do think it is a big deal, the obvious >> solution to it is send and OPTIONS message to find out if the server >> supports this. Most people don't seem to think this is enough of a >> problem to warrant and additional RTT when a UA boots. We can come up >> with other possible solutions to this too (as there are at least >> three others on this same thread). > > Conclusion: > - Sending OPTION has the drawback of extra RTT It seem to me that this will not happen in any practical deployment. It only has this limitation if the user types in the outbound proxy to the UA. Now perhaps this is the part I am not understanding - is there some deployment of lots of UAs where this is likely to happen and I am just not thinking of it? > - Further on in my understanding it is more complex solution > for both the UA and the proxy (more logic to be implemented > to both ends) compared to Proxy-Require solution I'm surprised at this conclusion but will listen to what folks say on this. > - I am not in favour of OPTION for those reasons > > 7.2 Sending STUN packets and waiting for responses > > Dean Willis: >> Cullen suggested an alternate possibility that might work. >> >> I'll try and paraphrase: >> >> A UAC which has an outbound URI indicating with ;keepalive=stun that >> the next hop can support STUN messages on the SIP port needs to >> verify the first hop supports STUN before repeatedly sending STUN >> messages. The UAC may initially try sending STUN messages to the SIP >> port of the first hop node. If the UAC does not receive a correct >> STUN response (within some timer?) then it must assume that this >> mode does not support STUN, and proceed without using STUN until it >> has some evidence that the first-hop node might have changed, in >> which case it retries the STUN requests as per the initial attempt. > > Hadriel Kaplan: >>> (3) checking a server supports a malformed message by actually >>> sending the malformed message is, well, simply rude. :) >>> It makes this draft a new torture test; > >> but what IETF RFC would actually mandate you to send SIP to your IMAP >> server, to see if the IMAP server also understands SIP? A > mis-configuration >> or user error is a very different context, I think. For example, in > one you >> blame the operator of the DNS, and in the other you blame the IETF. > > Conclusion: > - I am in an agreement with Hadriel on this. Getting an > explicit information by a query is much cleaner solution > than rather guessing the result from sending an arbitary > number of STUN packets and checking if any responses are > received. > > > It is probably obvious that I am not convinced by any > of the raised issues that the proposed Proxy-Require > technique would not work or that it could not easily > be added into SIP Outbound draft. So I am clearly in > favour of it. Whether or not the UA is mandated to > add Proxy-Require header to REGISTER does not matter > so much to me but I would hope to be able to design > UAs that have such a possibility. > > Regards, > > Erkki > > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Sat Aug 12 01:51:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBmNF-00012b-4U; Sat, 12 Aug 2006 01:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBmNC-00012W-Vt for sip@ietf.org; Sat, 12 Aug 2006 01:49:26 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBmNB-0005r6-FT for sip@ietf.org; Sat, 12 Aug 2006 01:49:26 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7C4nL7q030469; Sat, 12 Aug 2006 07:49:21 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Aug 2006 08:49:21 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Aug 2006 08:49:20 +0300 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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Sat, 12 Aug 2006 08:49:16 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F029A5E2A@esebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca9zm9ekKWGBU7yR0WcEVreqXpL/AABDKdA From: To: , X-OriginalArrivalTime: 12 Aug 2006 05:49:20.0768 (UTC) FILETIME=[0E9EE000:01C6BDD3] X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Cullen, Just have a look into my long email on the subject and issue 4 within it. In my email I explained like this that why I do not believe it is a huge problem=20 or if it would be a problem at all: Is the proposal really so complex at all ? I propose the following text for the Outbound draft: The UA SHOULD add a Proxy-Require header field with the=20 value "sip-stun" to its REGISTER request. When the UA receives 200 OK with Supported: Outbound it can be sure that the next hop will support STUN keepalives. The proxy MUST remove the "sip-stun" value from the=20 Proxy-Require header field and then remove the header=20 if no values remain before forwarding the request to the next hop. If you have any doubts whether it works or not, please look into RFC 3329 from which I copied this text and=20 modified it to sip-stun purpose. It is proven and widely=20 deployed technique within Sec-Agree. Regards, Erkki=20 >-----Original Message----- >From: ext Cullen Jennings [mailto:fluffy@cisco.com]=20 >Sent: 12.August.2006 08:10 >To: Hadriel Kaplan >Cc: SIP; Fredrik Thulin >Subject: Re: [Sip] Outbound Issues: slides 3 and 4 > > >On Aug 11, 2006, at 10:36 AM, Hadriel Kaplan wrote: > >> I don't understand how a proxy-require option tag is considered =20 >> complex, >> when one has to implement the other changes in this draft. > >The problem is not the proxy-require. The problem is the proxy =20 >removing things from the proxy-require header. > >Have you considered the solution that Bob proposed for this. It did =20 >not have this problem of modifying the proxy require and it seem to =20 >solve all of your concerns. > > >_______________________________________________ >Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Sat Aug 12 04:47:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBp7n-0005Pi-Go; Sat, 12 Aug 2006 04:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBp7l-0005Pd-CD for sip@ietf.org; Sat, 12 Aug 2006 04:45:41 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBp7k-0000P3-4G for sip@ietf.org; Sat, 12 Aug 2006 04:45:41 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7C8cFeY028464 for ; Sat, 12 Aug 2006 04:38:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 12 Aug 2006 11:45:38 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OWNER-AAA-DOCTORS@OPS.IETF.ORG Thread-Index: Aca9668Ot7dNKK+6Qrie6s4kT56zOAAAAAlg From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sip] Out of Office AutoReply: OWNER-AAA-DOCTORS@OPS.IETF.ORG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1105199942==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1105199942== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BDEB.AF34CF72" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BDEB.AF34CF72 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I am out of office on vacation. I will be back on August 21, 2006. I = will not read and respond to e-mails during this period. If you need to = contact me urgently, please leave a voice mail message at my office = number. Regards, Dan ------_=_NextPart_001_01C6BDEB.AF34CF72 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: OWNER-AAA-DOCTORS@OPS.IETF.ORG

I am out of office on vacation. I will be back on = August 21, 2006.  I will not read and respond to e-mails during = this period.  If you need to contact me urgently, please leave a = voice mail message at my office number.

Regards,

Dan

------_=_NextPart_001_01C6BDEB.AF34CF72-- --===============1105199942== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============1105199942==-- From sip-bounces@ietf.org Sat Aug 12 04:52:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBpCv-0001tk-U2; Sat, 12 Aug 2006 04:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBpCt-0001l6-TY for sip@ietf.org; Sat, 12 Aug 2006 04:50:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBoxu-0007vM-Ls for sip@ietf.org; Sat, 12 Aug 2006 04:35:30 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBoiz-0003Qe-4V for sip@ietf.org; Sat, 12 Aug 2006 04:20:06 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2BE954F00D4; Sat, 12 Aug 2006 10:19:51 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Aug 2006 10:19:50 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Aug 2006 10:19:50 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Sat, 12 Aug 2006 10:19:49 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1331@esealmw113.eemea.ericsson.se> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F029A5E2A@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca9zm9ekKWGBU7yR0WcEVreqXpL/AABDKdAAAU07YA= From: "Christer Holmberg \(JO/LMF\)" To: , , X-OriginalArrivalTime: 12 Aug 2006 08:19:50.0499 (UTC) FILETIME=[14C27B30:01C6BDE8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >Just have a look into my long email on the subject and issue 4 within it. In my email I explained like this that why I do=20 >not believe it is a huge problem or if it would be a problem at all: > > Is the proposal really so complex at all ? I propose > the following text for the Outbound draft: > >The UA SHOULD add a Proxy-Require header field with the value "sip-stun" to its REGISTER request. When the UA receives=20 >200 OK with Supported: Outbound it can be sure that the next hop will support STUN keepalives. Yes. But please remember that STUN keepalive can be used without outbound. So, the outbound proxy may support STUN keepalive, but the registrar does not support outbound. In that case you may still want to use STUN keepalive, but you will not get Supported: Outbound in the registration response. My proposal is still that the outbound proxy should be able to insert an indicator in the REGISTER request/response, indicating to the UAC that it supports STUN keep-alive. Now, in addition to that Proxy-Require could still be used, if the UAC wants to make sure the REGISTER doesn't reach the registrar unless the outbound proxy supports STUN keepalive. Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 13:05:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBwsr-0005xb-5l; Sat, 12 Aug 2006 13:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBwsq-0005xW-FT for sip@ietf.org; Sat, 12 Aug 2006 13:02:48 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBwsp-0000FY-5r for sip@ietf.org; Sat, 12 Aug 2006 13:02:48 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id A9B60170; Sat, 12 Aug 2006 13:02:46 -0400 From: "Hadriel Kaplan" To: "'David R Oran'" Subject: RE: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Sat, 12 Aug 2006 13:02:44 -0400 Message-ID: <042801c6be31$21480200$b7c8000a@acmepacket.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.2869 Thread-Index: Aca687hjDGQWg3+DT8Kucs+0q4Cx0gDN5bog X-Spam-Score: 1.2 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'Cullen Jennings' , 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Tuesday, August 08, 2006 10:05 AM > To: Hadriel Kaplan > Cc: 'Cullen Jennings'; 'IETF SIP List' > Subject: Re: [Sip] Comments on rosenberg-sip-identity-coexistence > > > If we don't support transit, why do we need an Identity-type > > mechanism? > > > For retargeting. I don't follow. Within a domain, I presume the retargeting is achieved by the proxies under control of the domain. If we don't care about transit, then again the question is why would an operator of the domain not believe the proxies retarget appropriately, when those will be the proxies that sign the connected-identity UPDATE message anyway. In other words the re-targeting path presumably follows a chain which had used whatever mechanism the operator decided was sufficient to authenticate the new target to begin with. Since the domain signs the upstream UPDATE message based on its belief that whatever authentication mechanism was used for the called party is sufficient, why bother? I could see its value if the re-targeting is performed either outside the domain, or the new target is outside the domain. But then we're back to the transit issues. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 13:14:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBx2P-00056e-G9; Sat, 12 Aug 2006 13:12:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBx2O-00056Z-Kt for sip@ietf.org; Sat, 12 Aug 2006 13:12:40 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBx2M-0000z3-By for sip@ietf.org; Sat, 12 Aug 2006 13:12:40 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 12 Aug 2006 10:12:38 -0700 X-IronPort-AV: i="4.08,117,1154934000"; d="scan'208"; a="1846485339:sNHT31054682" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7CHCbW9003187; Sat, 12 Aug 2006 10:12:37 -0700 Received: from [192.168.1.2] (sjc-vpn2-589.cisco.com [10.21.114.77]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7CHCauD028393; Sat, 12 Aug 2006 10:12:36 -0700 (PDT) In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F029A5E2A@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F029A5E2A@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9435CA97-BD83-4678-8A8A-46239090B6B6@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Sat, 12 Aug 2006 10:12:28 -0700 To: "" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=814; t=1155402757; x=1156266757; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=F8tmoNJmm7odluF3G3FfVb1Ah1a330mx+OOLoyQFR7nbAnN++5Bu6O7pzTWJiZr7u+y9XvcT sea5lPf3XAy9PBpK4PtaAn3FcNf3Lpg0+JwEvYvEYA/+qF0VXt3ljcoi; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 11, 2006, at 10:49 PM, wrote: > > The UA SHOULD add a Proxy-Require header field with the > value "sip-stun" to its REGISTER request. When the UA > receives 200 OK with Supported: Outbound it can be sure > that the next hop will support STUN keepalives. > > The proxy MUST remove the "sip-stun" value from the > Proxy-Require header field and then remove the header > if no values remain before forwarding the request to > the next hop. My mistake - it was some of the other stuff that was looking more complicated. I agree this is very easy implement. I also think Bob's proposal is very easy to implement - if the outbound proxy came from DHCP or was manually configured on the UA, then do an OPTIONS message first. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 13:56:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBxhM-0001Ze-JK; Sat, 12 Aug 2006 13:55:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBxhL-0001ZU-Gc for sip@ietf.org; Sat, 12 Aug 2006 13:54:59 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBxhL-000360-1f for sip@ietf.org; Sat, 12 Aug 2006 13:54:59 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 0863C20A2F6; Sat, 12 Aug 2006 17:54:29 +0000 (UTC) Message-Id: <7.0.1.0.0.20060810090324.02c1af60@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 10 Aug 2006 09:10:59 +0200 To: "Hadriel Kaplan" , "'Fredrik Thulin'" , From: Jiri Kuthan Subject: RE: [Sip] Outbound Issues: slides 3 and 4 In-Reply-To: <00a801c6bbde$ddffa3d0$b7c8000a@acmepacket.com> References: <200608091036.43395.ft@it.su.se> <00a801c6bbde$ddffa3d0$b7c8000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'Rohan Mahy' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 20:08 09/08/2006, Hadriel Kaplan wrote: >> -----Original Message----- >> From: Fredrik Thulin [mailto:ft@it.su.se] >> Sent: Wednesday, August 09, 2006 4:37 AM >> To: sip@ietf.org >> Cc: Rohan Mahy; Dean Willis >> Subject: Re: [Sip] Outbound Issues: slides 3 and 4 >> >> On Wednesday 09 August 2006 07:00, Rohan Mahy wrote: >> ... >> > I'm personally pretty happy with this, "if it ain't working, don't >> > keep doing it approach." >> > Could others comment if they like the approach or not? >> >> I am in favor of it, because ultimately there is no way to _know_ that >> the first hop actually handles STUN requests without sending one. >> >> The argument that a response containing something saying "I claim I can >> handle STUN requests you send me" is to be trusted, but configuration >> saying ";keepalive=stun" is not is flawed. > >Au contraire. I would argue fairly vehemently that a server explicitly >indicating it supports something is far more reliable than a UA believing >the server supports something based on a local config setting. The former >is an explicit indication by the guy who's responsible for doing that >mechanism, whether he can do it or not; the latter is a guess by the client >as to the other side's capabilities. Certainly the proxy can be wrong, but >that probability is miniscule to the odds that one UA out of a large >population will be wrong. > > >> The UA will still have to >> send a STUN request, and might or might not receive a response. > >It sure will. But if the proxy indicated support for sip-stun, that failure >would only occur if the proxy implementation was broken. It would not be >used as an active check mechanism. If the proxy is broken, it's under the >power of the owner of the proxy to fix it. If the UAs send STUN every-time >they boot-up or re-connect, it is not under the power of the owner of the >proxy to stop them if the proxy cannot explicitly indicate support/not. So you are saying that if a server is not broken and it properly offers its capabilities, it is then under its power to stop clients from doing silly things? Also, the extra STUN overhead caused on boot-ups and reconnects in addition to registration oveFrom sip-bounces@ietf.org Sat Aug 12 13:56:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBxhM-0001Ze-JK; Sat, 12 Aug 2006 13:55:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBxhL-0001ZU-Gc for sip@ietf.org; Sat, 12 Aug 2006 13:54:59 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBxhL-000360-1f for sip@ietf.org; Sat, 12 Aug 2006 13:54:59 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 0863C20A2F6; Sat, 12 Aug 2006 17:54:29 +0000 (UTC) Message-Id: <7.0.1.0.0.20060810090324.02c1af60@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 10 Aug 2006 09:10:59 +0200 To: "Hadriel Kaplan" , "'Fredrik Thulin'" , From: Jiri Kuthan Subject: RE: [Sip] Outbound Issues: slides 3 and 4 In-Reply-To: <00a801c6bbde$ddffa3d0$b7c8000a@acmepacket.com> References: <200608091036.43395.ft@it.su.se> <00a801c6bbde$ddffa3d0$b7c8000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'Rohan Mahy' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 20:08 09/08/2006, Hadriel Kaplan wrote: >> -----Original Message----- >> From: Fredrik Thulin [mailto:ft@it.su.se] >> Sent: Wednesday, August 09, 2006 4:37 AM >> To: sip@ietf.org >> Cc: Rohan Mahy; Dean Willis >> Subject: Re: [Sip] Outbound Issues: slides 3 and 4 >> >> On Wednesday 09 August 2006 07:00, Rohan Mahy wrote: >> ... >> > I'm personally pretty happy with this, "if it ain't working, don't >> > keep doing it approach." >> > Could others comment if they like the approach or not? >> >> I am in favor of it, because ultimately there is no way to _know_ that >> the first hop actually handles STUN requests without sending one. >> >> The argument that a response containing something saying "I claim I can >> handle STUN requests you send me" is to be trusted, but configuration >> saying ";keepalive=stun" is not is flawed. > >Au contraire. I would argue fairly vehemently that a server explicitly >indicating it supports something is far more reliable than a UA believing >the server supports something based on a local config setting. The former >is an explicit indication by the guy who's responsible for doing that >mechanism, whether he can do it or not; the latter is a guess by the client >as to the other side's capabilities. Certainly the proxy can be wrong, but >that probability is miniscule to the odds that one UA out of a large >population will be wrong. > > >> The UA will still have to >> send a STUN request, and might or might not receive a response. > >It sure will. But if the proxy indicated support for sip-stun, that failure >would only occur if the proxy implementation was broken. It would not be >used as an active check mechanism. If the proxy is broken, it's under the >power of the owner of the proxy to fix it. If the UAs send STUN every-time >they boot-up or re-connect, it is not under the power of the owner of the >proxy to stop them if the proxy cannot explicitly indicate support/not. So you are saying that if a server is not broken and it properly offers its capabilities, it is then under its power to stop clients from doing silly things? Also, the extra STUN overhead caused on boot-ups and reconnects in addition to registration overhead -- could you quantify how much worse it gets during stateless processing on top of the database-heavy registrations? >> I consider blacklisting an IP address that sends you one (1) packet you >> consider bad to be too aggressive. I wouldn't use a proxy that did >> that. > >It won't be 1 packet. The UAC will have to retransmit multiple times, >because as far as it knows packet loss happened. (btw, such proxies are >typically highly configurable in how they detect and handle such things) Why do you think this is a critical performance issue? I somehow fail to see why we should build in extra negotiation complexity when a client can just send a packet or few and see what happens. Servers have to deal with load anyhow and the relative contribution of STUN to the load appears rather marginal to me. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 13:56:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBxhN-0001bd-Ds; Sat, 12 Aug 2006 13:55:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBxhM-0001ZZ-DY for sip@ietf.org; Sat, 12 Aug 2006 13:55:00 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBxhK-00035v-Uy for sip@ietf.org; Sat, 12 Aug 2006 13:55:00 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 7D2EC20A2F3; Sat, 12 Aug 2006 17:54:29 +0000 (UTC) Message-Id: <7.0.1.0.0.20060810075256.02c19f38@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 10 Aug 2006 08:58:30 +0200 To: Dean Willis , Cullen Jennings From: Jiri Kuthan Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ... In-Reply-To: <3175E6C9-1E67-444E-AE87-1E26360384F9@softarmor.com> References: <3175E6C9-1E67-444E-AE87-1E26360384F9@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 23:18 09/08/2006, Dean Willis wrote: >I'm more worried about the scenario where the UA doesn't get >blacklisted, but just throws a monkeywrench in performance, and it >sucks just enough that people don't fix it but complain anyhow. well, I think we will be receiving useless traffic anyhow so addressing one of endlessly many sources of useless traffic doesn't bring us much further. With public SIP sites, we experience about 80% of "silly traffic" (caused typically by client/server misconfigurations and/or broken implementations). Folks who run national DNS servers shared with me similar numbers for DNS. Implementations have to be ready to deal with unwanted silly traffic. >>For these reasons, I don't think this whole problem is not a huge >>deal. However, if people do think it is a big deal, the obvious >>solution to it is send and OPTIONS message to find out if the >>server supports this. Most people don't seem to think this is rhead -- could you quantify how much worse it gets during stateless processing on top of the database-heavy registrations? >> I consider blacklisting an IP address that sends you one (1) packet you >> consider bad to be too aggressive. I wouldn't use a proxy that did >> that. > >It won't be 1 packet. The UAC will have to retransmit multiple times, >because as far as it knows packet loss happened. (btw, such proxies are >typically highly configurable in how they detect and handle such things) Why do you think this is a critical performance issue? I somehow fail to see why we should build in extra negotiation complexity when a client can just send a packet or few and see what happens. Servers have to deal with load anyhow and the relative contribution of STUN to the load appears rather marginal to me. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 13:56:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBxhN-0001bd-Ds; Sat, 12 Aug 2006 13:55:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBxhM-0001ZZ-DY for sip@ietf.org; Sat, 12 Aug 2006 13:55:00 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBxhK-00035v-Uy for sip@ietf.org; Sat, 12 Aug 2006 13:55:00 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 7D2EC20A2F3; Sat, 12 Aug 2006 17:54:29 +0000 (UTC) Message-Id: <7.0.1.0.0.20060810075256.02c19f38@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 10 Aug 2006 08:58:30 +0200 To: Dean Willis , Cullen Jennings From: Jiri Kuthan Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ... In-Reply-To: <3175E6C9-1E67-444E-AE87-1E26360384F9@softarmor.com> References: <3175E6C9-1E67-444E-AE87-1E26360384F9@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: IETF SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 23:18 09/08/2006, Dean Willis wrote: >I'm more worried about the scenario where the UA doesn't get >blacklisted, but just throws a monkeywrench in performance, and it >sucks just enough that people don't fix it but complain anyhow. well, I think we will be receiving useless traffic anyhow so addressing one of endlessly many sources of useless traffic doesn't bring us much further. With public SIP sites, we experience about 80% of "silly traffic" (caused typically by client/server misconfigurations and/or broken implementations). Folks who run national DNS servers shared with me similar numbers for DNS. Implementations have to be ready to deal with unwanted silly traffic. >>For these reasons, I don't think this whole problem is not a huge >>deal. However, if people do think it is a big deal, the obvious >>solution to it is send and OPTIONS message to find out if the >>server supports this. Most people don't seem to think this is >>enough of a problem to warrant and additional RTT when a UA boots. >>We can come up with other possible solutions to this too (as there >>are at least three others on this same thread). > >To recap: > >Unacceptable: If you're configured to use STUN, just keep STUNning >whether it works or not. You may be dead, but you're right, and >that's the important part. > > >Alternatives: > >1) Use an OPTIONS transaction before stunning to find out if the >target supports STUN >2) Use any other SIP transaction (like REGISTER) to find out if the >target supports STUN > a) using a Proxy-Require > b) Using some sort of Path: tagging >3) Just go ahead and STUN, and if it doesn't work, stop sending STUN. > >I'd be happy with 1+3 or 2+3. I'd even be happy with 1+3 where 1 is a >"SHOULD" strength, but 3 needs to be a MUST. It may be common sense, >but it requires documentation, and people seem to need "common sense" >to have a MUST priority on it or they pretend it isn't important. > >If we go the 1-SHOULD+3-MUST route, we need to include the "Because >the proxy might think your STUN is an attack or error condition and >black-list you" as the explanation for the SHOULD. I think we may have a general protocol design question whether to do some negotiation stuff or just try-and-error. I personally prefer the latter for sake of simplicity. That means I agree totally on three and I prefer not to do 1 or 2. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 >>enough of a problem to warrant and additional RTT when a UA boots. >>We can come up with other possible solutions to this too (as there >>are at least three others on this same thread). > >To recap: > >Unacceptable: If you're configured to use STUN, just keep STUNning >whether it works or not. You may be dead, but you're right, and >that's the important part. > > >Alternatives: > >1) Use an OPTIONS transaction before stunning to find out if the >target supports STUN >2) Use any other SIP transaction (like REGISTER) to find out if the >target supports STUN > a) using a Proxy-Require > b) Using some sort of Path: tagging >3) Just go ahead and STUN, and if it doesn't work, stop sending STUN. > >I'd be happy with 1+3 or 2+3. I'd even be happy with 1+3 where 1 is a >"SHOULD" strength, but 3 needs to be a MUST. It may be common sense, >but it requires documentation, and people seem to need "common sense" >to have a MUST priority on it or they pretend it isn't important. > >If we go the 1-SHOULD+3-MUST route, we need to include the "Because >the proxy might think your STUN is an attack or error condition and >black-list you" as the explanation for the SHOULD. I think we may have a general protocol design question whether to do some negotiation stuff or just try-and-error. I personally prefer the latter for sake of simplicity. That means I agree totally on three and I prefer not to do 1 or 2. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 16:24:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC00a-0002qj-Dv; Sat, 12 Aug 2006 16:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC00Z-0002qc-7P for sip@ietf.org; Sat, 12 Aug 2006 16:22:59 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GC00Y-0005e2-TE for sip@ietf.org; Sat, 12 Aug 2006 16:22:59 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id A8A101B0; Sat, 12 Aug 2006 16:22:57 -0400 From: "Hadriel Kaplan" To: "'Jiri Kuthan'" , Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Sat, 12 Aug 2006 16:22:54 -0400 Message-ID: <043a01c6be4d$180b22a0$b7c8000a@acmepacket.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: <7.0.1.0.0.20060810090324.02c1af60@iptel.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca+OG1tCTxpA2NZTk2hH6sRhS+VGgACk2Kg X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hey Jiri, comments inline... > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org] > > >> The UA will still have to > >> send a STUN request, and might or might not receive a response. > > > >It sure will. But if the proxy indicated support for sip-stun, that > failure > >would only occur if the proxy implementation was broken. It would not be > >used as an active check mechanism. If the proxy is broken, it's under > the > >power of the owner of the proxy to fix it. If the UAs send STUN every- > time > >they boot-up or re-connect, it is not under the power of the owner of the > >proxy to stop them if the proxy cannot explicitly indicate support/not. > > So you are saying that if a server is not broken and it properly offers > its > capabilities, it is then under its power to stop clients from doing silly > things? I assume you mean if the server properly indicates it does not support stun, can it then stop a UA from sending stun? Of course not, if the UA is broken. Any proxy worth its salt has to be designed and implemented defensively, IMO, and needs to handle that locally. But that's not my point. My point is that what a non-stun proxy does in that case is unknowable/undefined, but at least that case is one where a device (the UA) is broken. An IETF standard should account for that if possible, within reason, but to make the "broken" case the default mechanism for checking this is simply not the same thing. When I say "it's under the power of the proxy owner to stop them", I mean assuming the UA is NOT broken. I would think a standard protocol would be written for operation under the "it's not broken" pretense, else we'd go nowhere. If we make the stun checking the default check, then a non-broken outbound UA checking a non-broken rfc 3261 proxy has undefined behavior, for the proxy. That is not the case for a proxy-require mechanism. > Also, the extra STUN overhead caused on boot-ups and reconnects in > addition > to registration overhead -- could you quantify how much worse it gets > during > stateless processing on top of the database-heavy registrations? Of course not - that would be implementation dependent. Nor did I say performance was an issue I was concerned with. (others may have) I said it would not be explicitly stoppable by the proxy every time (again assuming a non-broken UA), and by that I simply meant that this undefined behavior of a 3261-compliant proxy will happen more than once, whatever it may be. Maybe your point is that parsing a Register, detecting an unsupported proxy-require, and generating a 420 response is heavier than receiving some malformed messages and discarding them? That's a fair argument, though undoubtedly implementation dependent. I (naively) assume some proxies check the proxy-require before dipping a DB, but even then it's still probably heavier. You build stateless 3261-compliant proxies - is this performance issue the case? Is it enough of a performance issue that you care, considering this only happens at UA reboot/reconnect in the normal case? I am certain stun-checking (using stuns) will be less performance impact on my product. But I don't care - it won't outweigh the benefits of providing better troubleshooting ability for my customers. A proxy-require in a Register provides a lot of valuable information - such as the AoR that tried this, what it was requiring, etc. And it won't outweigh the benefits to SIP as a technology if we keep other proxies from crashing or whatever. I know you may not believe I have the interests of SIP as a technology at heart ;), but the best assurance I can give you of this is that every time a CERT gets issued, my company benefits. It is in my best monetary interest to have that happen, so in my best interest that we do no checking whatsoever. But I don't want it to happen, because SIP needs to be perceived by the general public and media as a sound protocol. (And that's also in my monetary interest, so you can think of that as my incentive if you wish) > >> I consider blacklisting an IP address that sends you one (1) packet you > >> consider bad to be too aggressive. I wouldn't use a proxy that did > >> that. > > > >It won't be 1 packet. The UAC will have to retransmit multiple times, > >because as far as it knows packet loss happened. (btw, such proxies are > >typically highly configurable in how they detect and handle such things) > > Why do you think this is a critical performance issue? It's not - I'm not concerned with performance for this. I was just pointing out it would be more than 1 packet, because the previous statement said it would be bad behavior to blacklist on "1" malformed packet. I was just being annoyingly specific really. :) -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 19:24:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC2ol-0007uR-3C; Sat, 12 Aug 2006 19:22:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC2oj-0007uM-IO for sip@ietf.org; Sat, 12 Aug 2006 19:22:57 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GC2oi-0005LA-6i for sip@ietf.org; Sat, 12 Aug 2006 19:22:57 -0400 Received: from [131.161.248.86] (open-131-161-248-86.cliq.com [131.161.248.86]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k7CNMZF29379; Sat, 12 Aug 2006 16:22:35 -0700 In-Reply-To: <02121a731098adcc1cfd384c487a3059@telio.no> References: <5EB80D22825EEE42872083AD5BFFB594017F132C@esealmw113.eemea.ericsson.se> <02121a731098adcc1cfd384c487a3059@telio.no> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <11f013d932b9febb0b110906993aa989@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Sat, 12 Aug 2006 16:23:05 -0700 To: Hisham Khartabil X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org, Rohan Mahy , Fredrik Thulin , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 11, 2006, at 6:50, Hisham Khartabil wrote: > On Aug 11, 2006, at 3:02 PM, Christer Holmberg ((JO/LMF)) wrote: >> Hi, >> >> I am sure that there are cases where messages (STUN, or whatever) will >> be sent to destinations that don't support them, e.g. due to bad >> configuration. >> >> MY problem is that I don't like to standardize behavior which is based >> on sending something somewhere just to find out if the reciever >> supports >> the protocol in the first place. That is the reason I want to be able >> to >> get the information from the proxy before sending anything. > > Rohan's proposal is exactly what you dont want: sending something just > to find out if the receiver supports the protocol. I am confused. The proposal the started this thread was to *include* a Proxy-Require when the UAC sends its first message. If the UAC was properly configured, this adds no additional overhead. The proposal that Dean and Cullen made subsequently is "try it once and see". Again, if the UAC is properly configured, there is no extra overhead. What part of these two proposals is not OK for you? thanks, -rohan _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 21:06:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC4Oa-0002A9-O7; Sat, 12 Aug 2006 21:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC4OZ-00028k-AA for sip@ietf.org; Sat, 12 Aug 2006 21:04:03 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GC4OW-0001Wx-Vl for sip@ietf.org; Sat, 12 Aug 2006 21:04:03 -0400 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7D16BXh015820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Aug 2006 20:06:12 -0500 Message-ID: <44DE7A94.6090802@softarmor.com> Date: Sat, 12 Aug 2006 20:04:20 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 References: <8B1D53AEF7B03449A6D3771B3B7F850F029A5E2A@esebe103.NOE.Nokia.com> <9435CA97-BD83-4678-8A8A-46239090B6B6@cisco.com> In-Reply-To: <9435CA97-BD83-4678-8A8A-46239090B6B6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > On Aug 11, 2006, at 10:49 PM, > wrote: > >> >> The UA SHOULD add a Proxy-Require header field with the >> value "sip-stun" to its REGISTER request. When the UA >> receives 200 OK with Supported: Outbound it can be sure >> that the next hop will support STUN keepalives. >> >> The proxy MUST remove the "sip-stun" value from the >> Proxy-Require header field and then remove the header >> if no values remain before forwarding the request to >> the next hop. > > My mistake - it was some of the other stuff that was looking more > complicated. I agree this is very easy implement. I also think Bob's > proposal is very easy to implement - if the outbound proxy came from > DHCP or was manually configured on the UA, then do an OPTIONS message > first. Yay! How about we say: Either do 1 or 2 below, then always do 3: 1) Probe the proxy with OPTIONS to verify that it supports STUN or 2) Use a Proxy-Require as above and 3) if you don't get a STUN response, stop using STUN on this target (and I'd be happy to see this in STUN, not Outbound!) -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 12 23:09:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC6Jr-0001tc-S9; Sat, 12 Aug 2006 23:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC6Jq-0001tX-PQ for sip@ietf.org; Sat, 12 Aug 2006 23:07:18 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GC6Jp-0006oa-Gj for sip@ietf.org; Sat, 12 Aug 2006 23:07:18 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id A759037C; Sat, 12 Aug 2006 23:07:05 -0400 From: "Hadriel Kaplan" To: "'Dean Willis'" , "'Cullen Jennings'" Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Sat, 12 Aug 2006 23:07:01 -0400 Message-ID: <000c01c6be85$8c94fd20$6601a8c0@acmepacket.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: <44DE7A94.6090802@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Aca+dGxayke3VL01TxeRqyC8yzZUpwAD90Fw X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > How about we say: > > Either do 1 or 2 below, then always do 3: > > 1) Probe the proxy with OPTIONS to verify that it supports STUN > > or > > 2) Use a Proxy-Require as above > > and > > 3) if you don't get a STUN response, stop using STUN on this target (and > I'd be happy to see this in STUN, not Outbound!) Sounds great! I assume (2) means in the first Register. For (3) you need to specify how many stun attempts before giving up. (3 tries?) -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sun Aug 13 02:28:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC9QD-0000Nq-OJ; Sun, 13 Aug 2006 02:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC9QC-0000Nb-1j for sip@ietf.org; Sun, 13 Aug 2006 02:26:04 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GC9Q7-0001je-Gf for sip@ietf.org; Sun, 13 Aug 2006 02:26:04 -0400 Received: from [12.36.197.2] (helo=JMHLap3.stevecrocker.com) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GC9Q7-0006O4-3S for sip@ietf.org; Sun, 13 Aug 2006 02:25:59 -0400 Message-Id: <7.0.1.0.0.20060813022533.04017ec0@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 13 Aug 2006 02:25:57 -0400 To: sip@ietf.org From: "Joel M. Halpern" Subject: Re: [Sip] Outbound Issues: slides 3 and 4 In-Reply-To: <44DE7A94.6090802@softarmor.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F029A5E2A@esebe103.NOE.Nokia.com> <9435CA97-BD83-4678-8A8A-46239090B6B6@cisco.com> <44DE7A94.6090802@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120ec9fdb2dba165b7e7c78a021226f35f019bd390addb7d5d0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.36.197.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I can live with that. Joel At 09:04 PM 8/12/2006, Dean Willis wrote: >Cullen Jennings wrote: >>On Aug 11, 2006, at 10:49 PM, >> wrote: >> >>> >>>The UA SHOULD add a Proxy-Require header field with the >>>value "sip-stun" to its REGISTER request. When the UA >>>receives 200 OK with Supported: Outbound it can be sure >>>that the next hop will support STUN keepalives. >>> >>>The proxy MUST remove the "sip-stun" value from the >>>Proxy-Require header field and then remove the header >>>if no values remain before forwarding the request to >>>the next hop. >>My mistake - it was some of the other stuff that was looking more >>complicated. I agree this is very easy implement. I also think >>Bob's proposal is very easy to implement - if the outbound proxy >>came from DHCP or was manually configured on the UA, then do an >>OPTIONS message first. > > >Yay! > > >How about we say: > >Either do 1 or 2 below, then always do 3: > >1) Probe the proxy with OPTIONS to verify that it supports STUN > >or > >2) Use a Proxy-Require as above > >and > >3) if you don't get a STUN response, stop using STUN on this target >(and I'd be happy to see this in STUN, not Outbound!) > >-- >Dean > >_______________________________________________ >Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Sun Aug 13 05:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCBvx-0008Tf-2X; Sun, 13 Aug 2006 05:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCBvv-0008Ta-5d for sip@ietf.org; Sun, 13 Aug 2006 05:06:59 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCBvt-000641-N7 for sip@ietf.org; Sun, 13 Aug 2006 05:06:59 -0400 Received: (qmail 31064 invoked by uid 0); 13 Aug 2006 09:06:54 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 13 Aug 2006 09:06:54 -0000 Message-ID: <001001c6beb7$cf261570$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , "Joel M. Halpern" References: <8B1D53AEF7B03449A6D3771B3B7F850F029A5E2A@esebe103.NOE.Nokia.com><9435CA97-BD83-4678-8A8A-46239090B6B6@cisco.com><44DE7A94.6090802@softarmor.com> <7.0.1.0.0.20060813022533.04017ec0@stevecrocker.com> Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Sun, 13 Aug 2006 11:06:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Slightly modified proposal: 1) UA MUST verify that the proxy supports STUN before sending it 2) UA MUST stop sending STUN if no response (with reasonable defined retry interval, perhaps next boot?) For (1) we then have 2 defined alternatives: 1a) using OPTIONS 1b) using Proxy-Require but in addition, we should allow for alternative indications/mechanisms that may be defined in future drafts (such as a flag in Service-Route) Regards, Jeroen ----- Original Message ----- From: "Joel M. Halpern" To: Sent: Sunday, August 13, 2006 8:25 AM Subject: Re: [Sip] Outbound Issues: slides 3 and 4 >I can live with that. > Joel > > At 09:04 PM 8/12/2006, Dean Willis wrote: >>Cullen Jennings wrote: >>>On Aug 11, 2006, at 10:49 PM, >>> wrote: >>> >>>> >>>>The UA SHOULD add a Proxy-Require header field with the >>>>value "sip-stun" to its REGISTER request. When the UA >>>>receives 200 OK with Supported: Outbound it can be sure >>>>that the next hop will support STUN keepalives. >>>> >>>>The proxy MUST remove the "sip-stun" value from the >>>>Proxy-Require header field and then remove the header >>>>if no values remain before forwarding the request to >>>>the next hop. >>>My mistake - it was some of the other stuff that was looking more >>>complicated. I agree this is very easy implement. I also think Bob's >>>proposal is very easy to implement - if the outbound proxy came from DHCP >>>or was manually configured on the UA, then do an OPTIONS message first. >> >> >>Yay! >> >> >>How about we say: >> >>Either do 1 or 2 below, then always do 3: >> >>1) Probe the proxy with OPTIONS to verify that it supports STUN >> >>or >> >>2) Use a Proxy-Require as above >> >>and >> >>3) if you don't get a STUN response, stop using STUN on this target (and >>I'd be happy to see this in STUN, not Outbound!) >> >>-- >>Dean >> >>_______________________________________________ >>Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Sun Aug 13 06:34:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCDGi-0003TK-35; Sun, 13 Aug 2006 06:32:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCDGg-0003TF-Ar for sip@ietf.org; Sun, 13 Aug 2006 06:32:30 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCDGe-0003HA-KK for sip@ietf.org; Sun, 13 Aug 2006 06:32:30 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 620DA4F00F6; Sun, 13 Aug 2006 12:32:27 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Aug 2006 12:32:26 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Aug 2006 12:32:26 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Sun, 13 Aug 2006 12:32:26 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1332@esealmw113.eemea.ericsson.se> In-Reply-To: <792A45F8-C20F-4113-9F1E-458F0702F2D6@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca9zebMVbd+NH/RRTunp+wyDDYaSAAGjb1g From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" X-OriginalArrivalTime: 13 Aug 2006 10:32:26.0635 (UTC) FILETIME=[C5663DB0:01C6BEC3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org, Fredrik Thulin , rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>MY problem is that I don't like to standardize behavior which is based >>on sending something somewhere just to find out if the reciever=20 >>supports the protocol in the first place. > >I will point out that when a UA is configured to send requests to sip:example.com:5060 the way we find out if that port=20 >on that machine supports SIP is by sending a SIP request to it. I'm not sure I fully grasp the difference here.=20 The difference is the following:=20 If your UA is configured with a SIP address, the UA assumes SIP is supported. But, if it is not possible to configure (e.g. If the UA only gets the IP address of the outbound proxy) whether the outbound proxy supports STUN or not, I think it's bad that the UA shall start sending STUN requests in order to find out whether the outbound proxy supports STUN or not. >However, have you thought about Bob's proposal - it seems like it might be the thing that everyone can live with. I'll comment that separately. Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sun Aug 13 12:19:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCIeC-0008WR-MZ; Sun, 13 Aug 2006 12:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCIeA-0008W2-DQ for sip@ietf.org; Sun, 13 Aug 2006 12:17:07 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCIe9-0004Mj-3Z for sip@ietf.org; Sun, 13 Aug 2006 12:17:06 -0400 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7DGJIES007622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Aug 2006 11:19:18 -0500 Message-ID: <44DF509A.9090906@softarmor.com> Date: Sun, 13 Aug 2006 11:17:30 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Outbound Issues: slides 3 and 4 References: <8B1D53AEF7B03449A6D3771B3B7F850F029A5E2A@esebe103.NOE.Nokia.com><9435CA97-BD83-4678-8A8A-46239090B6B6@cisco.com><44DE7A94.6090802@softarmor.com> <7.0.1.0.0.20060813022533.04017ec0@stevecrocker.com> <001001c6beb7$cf261570$31713b51@BEMBUSTER> In-Reply-To: <001001c6beb7$cf261570$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, "Joel M. Halpern" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Slightly modified proposal: > > 1) UA MUST verify that the proxy supports STUN before sending it > 2) UA MUST stop sending STUN if no response (with reasonable defined > retry interval, perhaps next boot?) > > For (1) we then have 2 defined alternatives: > 1a) using OPTIONS > 1b) using Proxy-Require > > but in addition, we should allow for alternative indications/mechanisms > that may be defined in future drafts (such as a flag in Service-Route) > works for me. -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sun Aug 13 19:00:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCOuD-0006UG-PU; Sun, 13 Aug 2006 18:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCOuC-0006UB-JK for sip@ietf.org; Sun, 13 Aug 2006 18:58:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCOuB-000194-8X for sip@ietf.org; Sun, 13 Aug 2006 18:58:04 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 13 Aug 2006 15:58:03 -0700 X-IronPort-AV: i="4.08,119,1154934000"; d="scan'208"; a="311404111:sNHT33287264" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7DMw2c6026457; Sun, 13 Aug 2006 15:58:02 -0700 Received: from [192.168.1.2] (sjc-vpn7-466.cisco.com [10.21.145.210]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7DMw1IZ011961; Sun, 13 Aug 2006 15:58:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Sun, 13 Aug 2006 15:57:56 -0700 To: SIP X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=3561; t=1155509882; x=1156373882; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Outbound=20-=20a=20new=20STUN=20keealive=20proposal; X=v=3Dcisco.com=3B=20h=3DB7k2K4VUwIL6MltjB2ACVTaO9i0=3D; b=K2Qn29WI6DhMs/KxspuvhFiI1xXNEzmu65RUiEQvktT4mGttWv0v/xVfdxNVOEGEThCl58Vb p4RXDrbC8WHOdHismT/6N0kZKzSjnFXjjM77SodQPPOcMFh7IHEXaOzZ; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Rohan Mahy Subject: [Sip] Outbound - a new STUN keealive proposal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Rohan and I spent some time this afternoon trying to find a proposal that makes more people happy than the other proposals mentioned about STUN keepalive handling. We did this because some people expressed concern or displeasure about one proposal or another, but keep in mind that both of us are fine with the draft as is, in regards to this topic. What we are proposing is the following: 1) We already agreed to move the STUN keepalive definition to a separate section. This makes it clear how to use STUN keepalives even for implementations that do not use the rest of outbound. This is agreed - we are doing it, just listing it here for completeness. 2) Following the basic principle of "do no harm", we propose adding text to tell UAs that if an initial STUN request and its retransmissions fail, the UA MUST stop sending STUN requests to this destination. The details of how to specify this will be difficult to articulate succinctly, but we'd like to get agreement to this idea in principle. The difficulty is that if a flow fails completely, this is not necessarily indicative that the server has forgotten how to do STUN. 3) In the same vein, we propose adding text to make it clearer that a UA MUST NOT send STUN requests unless it has an explicit indication that the target SIP server supports STUN. We can further clarify that UA implementations should not have an ambiguous manual configuration option such as a "Work with NATs?" checkbox that would cause STUN keepalives to be used blindly. Manual configuration of an outbound URI that includes the ";keealive=stun" parameter is considered an explicit indication. Now on to the new part of the proposal... 4) In the STUN keepalive section of the document, define a "sip-stun" option-tag and describe its semantics (this server can receive STUN messages and SIP messages on the same port). Describe that an OPTIONS message MAY be used to probe or verify if a specific server supports sip-stun. Future specifications can define other uses of this option- tag. This leaves our options open as a WG. 5) In the outbound portion of the draft, make it clear that the first- hop proxy MUST support the "sip-stun" option-tag. (If the UA probes the first-hop, the probe needs to succeed). 6) Also in the outbound section of the draft, explain that that it is NOT RECOMMENDED for a UAC to include a Proxy-Require header field with the sip-stun option-tag. This is because the request would fail in some topologies where the first proxy supports sip-stun but subsequent proxies do not. Remind implementors that RFC 3261 does not allow proxies to remove option-tags from a Proxy-Require header field. To summarize this proposal: - It does no harm: It insures STUN is only used when explicitly configured and provides supportive implementation guidance, and it stops sending STUN if the server does not respond to initial STUN traffic. - It leaves our options open, while allowing outbound to progress: It keeps the door open for future explicit discovery mechanisms, and allows other potential uses of STUN keepalives. - It works. Please reply to the list or to (the chairs and authors) with one of the following choices: a) This is fine/good/OK b) I can live with this proposal, but prefer omitting the "sip-stun" option-tag c) I object (please provide reasons) d) I don't care, just please finish the document Thanks, Cullen & Rohan _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sun Aug 13 19:05:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCOzZ-0000f0-94; Sun, 13 Aug 2006 19:03:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCOzX-0000ev-IN for sip@ietf.org; Sun, 13 Aug 2006 19:03:35 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCOzW-0001V9-9b for sip@ietf.org; Sun, 13 Aug 2006 19:03:35 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 13 Aug 2006 16:03:33 -0700 X-IronPort-AV: i="4.08,119,1154934000"; d="scan'208"; a="1846634345:sNHT32730192" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7DN3XmX027317; Sun, 13 Aug 2006 16:03:33 -0700 Received: from [192.168.1.2] (sjc-vpn7-466.cisco.com [10.21.145.210]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7DN30uE021665; Sun, 13 Aug 2006 16:03:31 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1332@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F1332@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Sun, 13 Aug 2006 16:03:28 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1186; t=1155510213; x=1156374213; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204; X=v=3Dcisco.com=3B=20h=3DZLR+TF9yI0QSBHRXctM+MX7+B2g=3D; b=NXP1yh5x/YIi/Raz0fx4uYs7BdXVsg4ZtJBK+GkuTetXWAH7evu6bixAG9Lb163jYPshm1nc roS8pTALy7VYlHCKFR8RyAXtJICezvw4iKVRicsyR/DytJq6Oup+bmK2; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, Fredrik Thulin , rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 13, 2006, at 3:32 AM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >>> MY problem is that I don't like to standardize behavior which is >>> based > >>> on sending something somewhere just to find out if the reciever >>> supports the protocol in the first place. >> >> I will point out that when a UA is configured to send requests to > sip:example.com:5060 the way we find out if that port >> on that machine supports SIP is by sending a SIP request to it. >> I'm not > sure I fully grasp the difference here. > > The difference is the following: > > If your UA is configured with a SIP address, the UA assumes SIP is > supported. > > But, if it is not possible to configure (e.g. If the UA only gets > the IP > address of the outbound proxy) whether the outbound proxy supports > STUN > or not, I think it's bad that the UA shall start sending STUN requests > in order to find out whether the outbound proxy supports STUN or not. > 100% agree - I don't think the draft suggest this. I would be happy to add explicit text to the draft to say don't even think of doing something like this if that is causing confusion for people. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sun Aug 13 22:12:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCRuF-0006Pv-1t; Sun, 13 Aug 2006 22:10:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCRuD-0006Pk-2j for sip@ietf.org; Sun, 13 Aug 2006 22:10:17 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCRuB-0006Cs-Vl for sip@ietf.org; Sun, 13 Aug 2006 22:10:17 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id B719A222425 for ; Sun, 13 Aug 2006 19:18:14 -0700 (PDT) To: sip@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Sun, 13 Aug 2006 19:10:15 -0700 From: Eric Rescorla Message-Id: <20060814021814.B719A222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Subject: [Sip] Comments on draft-ietf-sip-gruu-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org GENERAL COMMENTS I found this document very hard to read. At root, the concept is extremely simple, but the document is 40 pages. IMO it could stand to be put on a pretty serious diet. I realize that this is an editorial comment, and I suppose it's not necessarily a showstopper, but I think it presents a pretty substantial obstacle to implementor understanding--at least it would if I were doing the implementation. In particular, pages 13-23 contain descriptions of the behaviors expected of various elements in the system. It's quite hard to tell from the text which behaviors are new to this specification and which are simply inherited from other specs and being described here for expository reasons. For instance, here's S 8.1.2: There is no new behavior associated with sending a request to a GRUU. A GRUU is a URI like any other. When a UA receives a request or response, it knows that the remote target is a GRUU by the presence of the "gruu" URI parameter. The UA can take the GRUU, send a request to it, and then be sure that the request is delivered to the UA instance which sent the request or response. If the GRUU contains the "opaque" URI parameter, a UA can obtain the AOR for the user by stripping the "opaque" and "gruu" URI parameters. The resulting URI is the AOR. If the GRUU does not have the "opaque" URI parameter, there is no mechanism defined for determining the AOR from the GRUU. Extraction of the AOR from the GRUU is useful for call logs and other accounting functions where it is desirable to know the user to whom the request was directed. Because the instance ID is a callee capabilities parameter, a UA might be tempted to send a request to the AOR of a user, and include an Accept-Contact header field [19] that indicates a preference for routing the request to a UA with a specific instance ID. Although this would appear to have the same effect as sending a request to the GRUU, it does not. The caller preferences expressed in the Accept- Contact header field are just preferences. Its efficacy depends on a UA constructing an Accept-Contact header field that interacts with domain-processing logic for an AOR, to cause a request to route to a particular instance. Given the variability in routing logic in a domain (for example, time-based routing to only selected contacts), this doesn't work for many domain-routing policies. However, this specification does not forbid a client from attempting such a request, as there may be cases where the desired operation truly is a preferential routing request. The only normative text here is the first sentence, which tells us that there's no new behavior. The rest is purely expository. After reading it, I'm not sure that it's necessary at all, but if it is it should be clearly separated from the normative text. I would advise trying to separate the new normative behavior into separate sections. I would advise intermixing examples with the main text and then having an extended example at the end. Just having a single extended example that people have to refer back to makes it very hard to get the idea of what's going on. TECHNICAL COMMENTS I'm a bit concerned about a lack of generality in this design. At some level, the idea here is that you have some URI X and you'd like to be able to create subordinate URIs XY and XZ such that they both correspond to X in (at least the following ways): 0. Either XY or XZ can speak for X. 1. A peer can address X and he will end up speaking to XY or XZ. 2. A peer can directly address XY and XZ and will end up at the right place. This specification provides two mechanisms for doing this: 1. opaque=, which is switched at the proxy. 2. grid=, which is switched at the end-instance. This seems like a not very general design. In particular, it would be able to use the same mechanism (e.g., name extension). Second, it seems like there's a real possibility we might want to be able to perform this same trick in some other context, in which case won't we need to invent some new demultiplexing indicator? It may be too late to redesign things to this extent, but that doesn't mean this isn't a real issue. Why is it necessary to have GRUUs which are (1) identifiable as GRUUs to peers but (2) can't be translated back to the AOR by the peer? EDITORIAL COMMENTS Abstract: Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. I would add after this "as opposed to the AOR, which may map to multiple UA instances" S 1: I don't find this section very clear at all. It manages to hide the key point about wanting to be able to address specific UAs rather than the AOR sort of implicitly in para 2. I would take one such one of the examples in S 4 and glue it in here to make clear what the issue is. I would remove paras 3 and 4 entirely. I think they're not adding much value. S 2: Isn't the key point for "contact" that it's bound to a specific UA? S 3: I'm not sure that this discussion of properties adds a lot of value. It's not really referred to much later in the spec and just adds a lot of new concepts people need to absorb. In particular, I don't think that the first five properties (AOR through identity) are that relevant here. S 4: Having this many use cases doesn't add that much. I would just delete this section after moving one use case (REFER?) to the introduction. S 5: I didn't find this section that helpful. It seems to me that the key points to get across are: 1. You have one AOR but multiple GRUUs, each of which is tied to a specific UA 2. You can have multiple GRUUs tied to the same UA. 3. You can be addressed either by GRUU or AOR, with the latter going to some UA out of control of the addressor. 4. You (generally) get your GRUUs from your proxy. 5. There are two types of GRUUs, those which can be mapped back to the AOR (opaque=) and those which can't. Getting these points across, with a picture would, it seems to me, get the job done better than this text. I didn't find Figure 3 to be that clear, however. Maybe multiple figures? S 6: o When a GRUU is assigned to an instance ID/AOR pair, both SIP and SIPS GRUUs will be assigned. Only one will be returned, but both will exist. The SIPS URI may not always work, particularly if the proxy cannot establish a secure connection to the client. What does it mean to have a URI assigned that doesn't work? However, forwarding services, such as call forwarding, SHOULD NOT be provided for requests sent to a GRUU. The intent of the GRUU is to target a specific UA instance, and this is incompatible with forwarding operations. This seems to me to get into policy. Are you saying that I can't have my cell phone forward calls to some other phone just cause people call my cell number rather than my generic "EKR" AOR? S 8.1.1: If the UA instance has obtained multiple GRUUs for different AORs as a result of a registration, it SHOULD use one corresponding to the AOR used to send or receive the request. Isn't it a security condition for the peer that these match? S 12: Is there any way you can notate the "changed" headers so it's easier to see what this specification affects? Please show the INVITE in message 3 for completeness. In the subscribe on page 30, you have: location lookup on the Request-URI. It is translated into the contact for that instance, and then proxied to that contact. Note how the "grid" parameter is maintained, and the "gruu" parameter is no longer present. This only applies to the URI in the request line, not to the "To" line. The registrar notices that a different contact, sip:callee@192.0.2.1, is already associated with the same instance ID. It registers the new one too and returns both in the REGISTER response. Both have the same GRUU. However, only this new contact (the most recently registered one) will be used by the proxy for population in the target set. The registrar then generates the following response: Why is it a good idea to register both instead of replacing the old one? I appreciate this is in Outbound, but I don't much like it there either... S A.2: The algorithm described here treats encryption as a black-box in a way that is potentially severely cryptographically weak. In particular, you have: In many cases, it will be desirable to construct the GRUU in such a way that it will not be possible, based on inspection of the URI, to determine the Contact URI that the GRUU translates to. It may also be desirable to construct it so that it will not be possible to determine the instance ID/AOR pair associated with the GRUU. Whether a GRUU should be constructed with this property is a local policy decision. With these rules, it is possible to construct a GRUU without requiring the maintenance of any additional state. To do that, the URI would be constructed in the following fashion: user-part = "GRUU" | BASE64(E(K, (salt | " " | AOR | " " | instance ID))) Where E(K,X) represents a suitable encryption function (such as AES with 128-bit keys) with key K applied to data block X, and the "|" operator signifies concatenation. The single space (" ") between components is used as a delimiter, so that the components can easily be extracted after decryption. Salt represents a random string that prevents a client from obtaining pairs of known plaintext and ciphertext. A good choice would be at least 128 bits of randomness in the salt. You're assuming that you have a cipher that propagates differences, but not all ciphers do. For instance, block ciphers in ECB mode and stream ciphers (or CTR mode ciphers) do not. It's nowhere near specific enough to say "a suitable encryption function such as AES with 128-bit keys" As a second note, it's not safe to use stream cipher with the same key repeatedly, which is what's implied by this text. The correct procedure here isn't to use a *salt* but rather an IV. Yes, in the case of a block cipher this gets prepended to the data (at least notionally) but in the case of a CTR-mode cipher it's used as part of the counter block. Encryption is needed to prevent attacks whereby the server is sent requests with fake GRUUs, causing the server to direct requests to any named URI. Even with encryption, the proxy should validate the user part after decryption. In particular, the AOR should be managed by the proxy in that domain. Encryption doesn't provide this service. If, for instance, you used a stream cipher or a block cipher in CTR mode, an attacker could still forge new GRUUs with chosen properties based on a known initial URI/GRUU pair. This is potentially even possible in CBC mode depending on how things are laid out. What you need here is an integrity check. Rather than trying to invent this token format, I would suggest you borrow one from an existing document, such as that in RFC 4507. Here's some text based on that: With these rules, it is possible to construct a GRUU without requiring the maintenance of any additional state. The proxy needs to store two randomly chosen secret keys: K_e -- used for encryption K_m -- used for integrity For each new GRUU, the proxy generates a fresh initialization vector (IV) I. It then computes: EA = E(K_e, AOR || " " || instance_ID) using initialization vector I where || indicates concatenation. The encryption algorithm SHOULD be chosen so that it is not feasible for an attacker two distinguish identical plaintexts when they are encrypted with distinct IVs. The encryption algorithm SHOULD be chosen to provide at least 80 bits of security, Suitable algorithms would include AES in cipher-block-chaining (CBC) mode [1] or counter (CTR) modes [2]. Note that if CTR mode is used, extreme care MUST be taken to ensure that not only are distinct IVs chosen but that the same section of keystream is never reused. Once EA has been computed, the proxy computes: HM = MAC(K_m, EA) Where HM is a suitable MAC function, such as HMAC-SHA1 [3]. The GRUU is then constructed as: user-part = "GRUU" || BASE64(EA || HM) This mechanism uses the user-part of the SIP URI to convey the encrypted AOR and instance ID. The user-part is used instead of the "opaque" URI parameter because it has the desired anonymity properties. The benefit of this mechanism is that a server need not store additional information on mapping a GRUU to its corresponding contact. The user-part of the GRUU contains the instance ID and AOR. Assuming that the domain stores registrations in a database indexed by the AOR, the proxy processing the GRUU would look up the AOR, extract the currently registered contacts, and find the one that matches the instance ID encoded in the Request-URI. The contact whose instance ID is that instance ID is then used as the translated version of the GRUU. Message integrity is needed to prevent attacks whereby the server is sent requests with fake GRUUs, causing the server to direct requests to any named URI. While this approach has many benefits, it has the drawback of producing somewhat longer GRUUs because of expansion due to the padding and base64 encoding. [1] National Institute of Standards and Technology, Specification for the Advanced Encryption Standard (AES)" FIPS 197. November 26, 2001. [2] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004. [3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 01:39:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCV8i-00050f-VA; Mon, 14 Aug 2006 01:37:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCV8h-00050a-QC for sip@ietf.org; Mon, 14 Aug 2006 01:37:27 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCV8e-0002lJ-UI for sip@ietf.org; Mon, 14 Aug 2006 01:37:27 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Mon, 14 Aug 2006 07:37:23 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Aug 2006 07:37:23 +0200 Message-Id: <85108216918A984C8C60172D7C84770A56F5F6@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: pkyzivat@cisco.com, ranarang@cisco.com Subject: AW: [Sip] updated acr code draft Date: Mon, 14 Aug 2006 07:37:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec Cc: sip@ietf.org, sanjsinh@cisco.com, maltarai@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ACR seen from service perspective on a strict line should forbid any = anonymous behaviour also the below described Xfer scenario. How I = release the call should be done due to SIP rules either with 433 or a = CANCEL or BYE including a Reason header with SIP 433. But there could be also some further scenarios that can be deployed as = mentioned below. I think this are valid scenarios and the user should = decide if he wants to restrict all anonymous calls or if he wants to = allow to pass such Xfer calls. BR Roland Jesske =20 > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Gesendet: Donnerstag, 10. August 2006 16:04 > An: Rajeev Narang (ranarang) > Cc: sip@ietf.org; Jesske, Roland; Sanjay Sinha (sanjsinh);=20 > Mohammad Al-Taraireh (maltarai) > Betreff: Re: [Sip] updated acr code draft >=20 >=20 > I think the behaviors you describe are all valid ones that the=20 > respective UAs may choose to do. And there are other=20 > behaviors that are=20 > equally valid that might be chosen. I don't think sip/sipping=20 > can/should=20 > define these, except as example call flows or maybe best=20 > practices. This=20 > is starting to get pretty deep into feature specification. >=20 > I think any of the participants in the scenario you describe=20 > should be=20 > prepared to deal with a variety of responses. As best I can=20 > tell, each=20 > one can be dealt with on its own without necessarily=20 > understanding the=20 > bigger picture of what is going on. That is a good thing, since in=20 > general none of the players will know the big picture. >=20 > More inline. >=20 > Paul >=20 > Rajeev Narang (ranarang) wrote: > > Hi, > >=20 > > I think Mohammad still hasn't got the clarification. > >=20 > > The scenario is:- > >=20 > > UA1----dialog1-------b2bua------dialog4----UA2 > > dialog2|dialog3 > > | > > UA3 > >=20 > > Say UA1 uses anonymous for its Name/Number. > > Say UA2 would reject the anonymous calls. > > UA3 is "not" using anonymous for its Name/Number and will=20 > "not" reject anonymous calls. > > =20 > > 1) UA1 calls UA3 (dialog1 and dialog2 are established) > > 2) UA3 puts UA1 on hold and does early attended Xfer to UA2=20 > (dialog3 and dialog4 are in early connected state, UA2 is=20 > still ringing). > > The dialog3/dialog4 INVITE dialogs will use the Name/Number=20 > of UA3 in the From header. So UA2 will allow it as dialog4=20 > > is not carrying anonymous Name/Id. > > 3) UA3 presses the Xfer button again to complete the early=20 > attended Xfer. > >=20 > > Now the identity info of UA1 will be communicated on=20 > dialog4 to UA2 in the UPDATE message say using RPID header.=20 > The INVITE dialog4 will not change the Display Name and Id in=20 > the From header as per the UA1's identity, so it will remain=20 > same as original, which is UA3's identity used during=20 > dialog3/dialog4 establishent. > >=20 > > The question is the handling of UA1's anonymity by UA2 in=20 > the UPDATE message and affect to the INVITE dialog4. > >=20 > > 1. Should UPDATE be responded with 433. >=20 > That is a choice to be made. It would be equally valid to=20 > conclude that=20 > one knew the original caller, (and so has someone to *blame*), and=20 > decide to trust the wisdom of the person doing the transfer. >=20 > For instance, suppose U3 is secretary and U4 is boss. The=20 > boss may never=20 > take anonymous calls, but the secretary does. The secretary=20 > acts as the=20 > screener for anonymous calls to the boss. >=20 > > How to handle the INVITE dialog4 as 200 OK is still not=20 > sent on dialog4. > > Based on 433 for UPDATE, b2bua can send CANCEL (With Reason=20 > Header carrying Q.850 cause=3D21 Rejected)to UA2 and UA2 can=20 > send 487 on dialog4.=20 > >=20 > > 2. Or UPDATE is responded with 433 and later 433 is sent on > INVITE dialog4 resulting in clearing the dialog4 on UA2 and b2bua. >=20 > While UA2 *could* do this, it doesn't make a lot of sense to me. Once = > the UPDATE is rejected, the dialog continues as it was=20 > before. There is=20 > no question of the identity of the caller (UA3) and so no=20 > reason to fail=20 > the call with a 433. User 3 and user 4 can continue to talk -=20 > with user=20 > 4 complaining to user 3 about trying to transfer an anonymous caller. >=20 > > Probably 433 followed by 180 on INVITE dialog will not look=20 > appropriate. >=20 > I don't follow. Which dialog? You can't send a 180 to an invite after = > having sent a 433 to the same invite. I don't see anything=20 > odd in other=20 > combinations. >=20 > > The dialog1 is already an established dialog so BYE will be sent. >=20 > Presumably this will happen if/when the b2bua has nothing else to=20 > connect it to. As long as UA3 is in the call I wouldn't expect that. >=20 > > The other scenario:- > > If it has been attended Xfer then dialog4 would have been=20 > already established. So in the same anonymous config the > > UPDATE could be responded with 433 >=20 > Certainly. >=20 > > and BYE with Reason header carrying SIP Status=3D433 could be=20 > sent from UA2 to b2bua on dialog4. >=20 > As I commented above, I don't see why you would want to do this. From = > UA2's perspective it still has a call with a known caller. If=20 > the b2bua=20 > can't maintain that (say because UA3 has sent a BYE) then the b2bua=20 > might need to send a BYE - to all the remaining parties. >=20 > > Could we get clarification on this so that standard=20 > approach can be used. >=20 > As I said above, I don't think there is, or need be, a broad standard = > for this. >=20 > Paul >=20 > > Regards, > > Rajeev > >=20 > >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > > Sent: Monday, August 07, 2006 10:26 AM > > To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha=20 > (sanjsinh); Jonathan Rosenberg (jdrosen); sip@ietf.org > > Subject: AW: [Sip] updated acr code draft > >=20 > > The UAC either should include the identity in the From=20 > header instead of anonymous or don't call again if the user=20 > still wants to be anonymous. > >=20 > > The UAS should close the transactions. > >=20 > > Best Regards > >=20 > > Roland > >=20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] > >> Gesendet: Freitag, 4. August 2006 16:13 > >> An: Jesske, Roland; Sanjay Sinha (sanjsinh); Jonathan Rosenberg=20 > >> (jdrosen); sip@ietf.org > >> Betreff: RE: [Sip] updated acr code draft > >> > >> > >> > >> The identity in the From header in not the correct party after the = > >> xfer is complete! I still don't see an answer to what=20 > should the UAC=20 > >> do when it gets the 433 response, or what the UAS should=20 > do after it=20 > >> send the 433, basically how does that response impact the INVITE=20 > >> dialog. > >> > >> Thanks, > >> > >> Mo > >> > >> -----Original Message----- > >> From: Jesske, R [mailto:R.Jesske@t-com.net] > >> Sent: Friday, August 04, 2006 4:14 AM > >> To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha=20 > (sanjsinh); Jonathan=20 > >> Rosenberg (jdrosen); sip@ietf.org > >> Subject: AW: [Sip] updated acr code draft > >> > >> There is a difference between an unavailable identity and=20 > a anonymous=20 > >> identity so that the endpoint can decide. > >> As a wrote before the From header is a mandatory header.=20 > So there must=20 > >> an identity in. > >> > >> In which scenario this early attended transfer could=20 > appear is this=20 > >> also a interworking case or a pure SIP case? > >> > >> What is with the identity I'm registering with? > >> > >> > >> BR > >> > >> Roland > >> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: Mohammad Al-Taraireh (maltarai) [mailto:maltarai@cisco.com] > >>> Gesendet: Donnerstag, 3. August 2006 16:22 > >>> An: Sanjay Sinha (sanjsinh); Jesske, Roland; Jonathan Rosenberg=20 > >>> (jdrosen); sip@ietf.org > >>> Cc: Mohammad Al-Taraireh (maltarai) > >>> Betreff: RE: [Sip] updated acr code draft > >>> > >>> > >>> > >>> Another case is a early attended transfer. For example=20 > the transfer=20 > >>> target will get an INVITE without caller id blocking and then an=20 > >>> UPDATE after the xfer with caller id blocking to change the > >> display.=20 > >>> If there is a policy on the endpoint to reject anonymous > >> calls, what > >>> should the do in this case? which the question below=20 > "what does 433=20 > >>> mean for mid call UPDATE or reINVITE?" > >>> > >>> Thanks, > >>> > >>> Mo > >>> > >>> -----Original Message----- > >>> From: Sanjay Sinha (sanjsinh) > >>> Sent: Thursday, August 03, 2006 9:57 AM > >>> To: Jesske, R; Jonathan Rosenberg (jdrosen); sip@ietf.org > >>> Subject: RE: [Sip] updated acr code draft > >>> > >>> Scenario is PSTN-SIP interworking. For some cases, display > >> IE is not > >>> available in SETUP because some TCAP query is required.=20 > >> When the query > >>> is complete, switch sends display IE in a FACILITY message. From=20 > >>> header is mandatory in INVITE, but calling name and number > >> is not. So > >>> Invite is sent without caller-identity which is later > >> updated with an > >>> UPDATE/INFO, when the UA gets FACILITY with display information. > >>> > >>> Thanks > >>> Sanjay.=20 > >>> > >>> -----Original Message----- > >>> From: Jesske, R [mailto:R.Jesske@t-com.net] > >>> Sent: Thursday, August 03, 2006 1:52 AM > >>> To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen);=20 > >>> sip@ietf.org > >>> Subject: AW: [Sip] updated acr code draft > >>> > >>> The ACR service itself reacts only on identities that are > >> put anonymus > >>> by the user or on behalf on the user. > >>> So if the restriction is based on other reasons ACR will > >> not terminate > >>> the call. > >>> > >>> My question to your scenario is in which case an identity is not=20 > >>> available in an INVITE. The From header is an mandatory > >> header so the > >>> >From Header has have an user identity. Or not? > >>> > >>> The P-Asserted-Identity is set by an trusted network=20 > entity that is=20 > >>> aware of the user sending that request. > >>> > >>> Best Regards > >>> > >>> Roland > >>> > >>>> -----Urspr=FCngliche Nachricht----- > >>>> Von: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > >>>> Gesendet: Mittwoch, 2. August 2006 17:32 > >>>> An: Jonathan Rosenberg (jdrosen); IETF SIP List > >>>> Betreff: RE: [Sip] updated acr code draft > >>>> > >>>> > >>>> What about the case in which caller information is not > >> available at > >>>> the time INVITE is sent to establish a call, but is > >> available later > >>>> and an UPDATE/INFO is sent by UAC to update the caller-id > >>> information. > >>>> If UAS rejects UPDATE/INFO with 433, what does it mean for > >>> the Invite > >>>> dialog. > >>>> Should that also be terminated as a result of ACR? > >>>> > >>>> Thanks > >>>> Sanjay > >>>> > >>>> -----Original Message----- > >>>> From: Jonathan Rosenberg (jdrosen) > >>>> Sent: Monday, July 31, 2006 4:31 PM > >>>> To: IETF SIP List > >>>> Subject: [Sip] updated acr code draft > >>>> > >>>> I've submitted a minor update to the ACR code draft. Until > >>> it appears, > >>>> you can pick it up at: > >>>> > >>>> http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt > >>>> > >>>> the changes are: > >>>> > >>>> * replaced P-Asserted-ID with P-Asserted-Identity > >>>> > >>>> * added to security considerations section, consideration for=20 > >>>> anonymizers in the network. Namely, don't retry request on > >>> receipt of > >>>> 433 unless explicitly configured to do so by user > >>>> > >>>> > >>>> Thanks, > >>>> Jonathan R. > >>>> --=20 > >>>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>>> Cisco Fellow Parsippany, NJ=20 > >>>> 07054-2711 > >>>> Cisco Systems > >>>> jdrosen@cisco.com FAX: =20 > >> (973) 952-5050 > >>>> http://www.jdrosen.net PHONE:=20 > >> (973) 952-5000 > >>>> http://www.cisco.com > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.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 > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.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 > >>>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.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 = > >>> sipping@ietf.org for new developments on the application of sip > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.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 = > >>> sipping@ietf.org for new developments on the application of sip > >>> > >> _______________________________________________ > >> Sip mailing list https://www1.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://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip > >=20 > > _______________________________________________ > > Sip mailing list https://www1.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 >=20 > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 02:36:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCW1r-0001fC-Om; Mon, 14 Aug 2006 02:34:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCW1p-0001Zn-JR for sip@ietf.org; Mon, 14 Aug 2006 02:34:25 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCW1o-0001bo-6p for sip@ietf.org; Mon, 14 Aug 2006 02:34:25 -0400 Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k7E6YOvH003659 for ; Mon, 14 Aug 2006 02:34:24 -0400 Received: from SONUSINMAIL01.sonusnet.com ([10.128.254.7]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 02:34:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Aug 2006 12:04:19 +0530 Message-ID: <70798CF421F00F4DA018059E5B7EEB8C7A5BDA@sonusinmail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-sipping-dialogusage-02.txt Thread-Index: Aca/a6vhg1oTxT0IQdO3kIXzBLjzNA== From: "B, Nataraju" To: X-OriginalArrivalTime: 14 Aug 2006 06:34:23.0618 (UTC) FILETIME=[AE788E20:01C6BF6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Subject: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1251298182==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1251298182== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BF6B.AC1AB8A4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BF6B.AC1AB8A4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3BhcmtzLCANCg0KIA0KDQpJIGhhZCBnb25lIHRocm91Z2ggdGhlIGRvY3VtZW50LCBoZXJl IGFyZSBmZXcgY29tbWVudHMuIA0KDQogDQoNCk5vdGU6IEkgYXNzdW1lIHRoZSBiZWhhdmlvciBt ZW50aW9uZWQgaW4gc2VjIDQgYXBwbGllcyBib3RoIGF0IGNsaWVudCByZWNlaXZpbmcgdGhlc2Ug cmVzcG9uc2VzIChOb3RpZmllcikgYW5kIHNlcnZlciBnZW5lcmF0aW5nIHRoZXNlIHJlcGxpZXMg KFN1YnNjcmliZXIpLiBJZiB0aGlzIHdhcyBtZWFudCB0byBiZSBvbmx5IEAgc2VuZGVyIG9mIE5P VElGWSBzaGFsbCB3ZSBuZWVkIHRvIG1lbnRpb24gdGhlIHNpbWlsYXIgc2V0IG9mIGFjdGlvbnMg QCBTdWJzY3JpYmVyIHNpZGUgdG9vPyANCg0KIA0KDQoxLiBTZWMgNCBkZXNjcmliZXMgd2hhdCB0 aGUgZWZmZWN0cyBvbiBkaWFsb2cgYXJlIGFuZCBpdHMgdXNhZ2VzIHdoZW4gcGFydGljdWxhciBy ZXNwb25zZXMgYXJlIHJlY2VpdmVkIGZvciBOT1RJRlkgbWVzc2FnZSwgdGhlIHJlc3BvbnNlcyA0 MDQsIDQxMCwgNDE2LCBsZWFkIHRvIGRpYWxvZyBhbmQgaXRzIHVzYWdlIHRlcm1pbmF0aW9uLiAN Cg0KICAgICAgYS4gSSBmZWVsIHdlIHNob3VsZCBoYXZlIG1lbnRpb25lZCBPTkxZIHRoZSBhdXRo ZW50aWNhdGVkIE5PVElGWSByZXF1ZXN0cyB3aWxsIGhhdmUgdGhpcyBlZmZlY3Qgb24gdGhlIGRp YWxvZ3MvdXNhZ2VzLiBPdGhlcndpc2UgYW55IG1pZGRsZSBtZW4gY2FuIHRyYWNlIHRoZSBtZXNz YWdlIGFuZCBzZW5kIHRoZSBOT1RJRlkgbWVzc2FnZXMgd2hpY2ggdGVybWluYXRlIHRoZSBkaWFs b2dzLCB3aGljaCBpcyB1bmRlc2lyYWJsZSDimLkuIElmIHRoZSBlbnRpdHkgc2VuZGluZyBOT1RJ RlkgcmVhbGx5IGludGVuZCB0byBkbyB0aGF0IGl0IGNhbiByZXNlbmQgTk9USUZZIHdpdGggYXV0 aG9yaXphdGlvbiBjcmVkZW50aWFscyB3aGljaCB3aWxsIGhlbHAgdG8gdGVybWluYXRlIHRoZSBh c3NvY2lhdGVkIGRpYWxvZ3MuDQoNCiANCg0KICAgICAgYi4gT3RoZXIgYWx0ZXJuYXRpdmUgd291 bGQgYmUgdGhhdCBsZXQgdGhvc2UgcmVzcG9uc2VzIGhhdmUgbm8gZWZmZWN0IG9uIHRoZSBkaWFs b2cvdXNhZ2VzLCBldmVudHVhbGx5IHRoZSBzdWJzY3JpcHRpb24gZHVyYXRpb24gd291bGQgdGFr ZSBjYXJlIG9mIGRpYWxvZyB0ZXJtaW5hdGlvbiBvciB0aGUgYWN0dWFsIGVudGl0eSB3b3VsZCB0 ZXJtaW5hdGUgb3IgZXh0ZW5kIHRoZSBzdWJzY3JpcHRpb24uIEFueSB3YXkgdGhlIHJlcXVlc3Qg ZnJvbSBhY3R1YWwgbm90aWZpZXIgd291bGQgaGF2ZSB0aGUgcHJvcGVyIFVSSXMgb3IgY3JlZGVu dGlhbHMgd2hpY2ggd2lsbCBuZXZlciBsZWFkIHRvIHRoZXNlIHJlc3BvbnNlcy4gDQoNCiANCg0K VGhlIHNhbWUgbG9naWMgd291bGQgbmVlZCB0byBleHRlbmQgZm9yIHJlcGxpZXMgNDgxLCA0ODMs IDQ4NCwgNDg5IGFuZCA2MDQgYWxzby4NCg0KIA0KDQoyLiBTZWMgNCBvZiB0aGUgZHJhZnQNCg0K ICAgDQoNCiAgICA8PDwgICA0MjMgSW50ZXJ2YWwgVG9vIEJyaWVmOiBUaGlzIHJlc3BvbnNlIHdv bid0IGhhcHBlbiBpbiBvdXIgZXhhbXBsZQ0KDQogICAgICBzY2VuYXJpbywgYnV0IGlmIGl0IGNh bWUgaW4gcmVzcG9uc2UgdG8gYSByZVNVQlNDUklCRSwgdGhlDQoNCiAgICAgIHN1YnNjcmliZSB1 c2FnZSBpcyBub3QgZGVzdHJveWVkIChvciBvdGhlcndpc2UgYWZmZWN0ZWQpLiAgTm8NCg0KICAg ICAgb3RoZXIgdXNhZ2VzIG9mIHRoZSBkaWFsb2cgYXJlIGFmZmVjdGVkLiA+Pj4NCg0KIA0KDQog ICAgICBJbiB0aGUgYWJvdmUgUGFyYSB0aGUgbWVhbmluZyBvZiBsYXN0IHBhcnQgb2YgMXN0IHNl bnRlbmNlIChJIG1lYW4sIHRoZSBzdWJzY3JpYmUgdXNhZ2UgaXMgbm90IGRlc3Ryb3llZCAob3Ig b3RoZXJ3aXNlIGFmZmVjdGVkKSkgYW5kIDJuZCBzZW50ZW5jZSBpcyBub3QgY2xlYXIsIGJvdGgg bWVudGlvbiB0aGUgc2FtZSBtZWFuaW5nPyBDYW4gd2UgbWFrZSBpdCBleHBsaWNpdCBhYm91dCB3 aGF0IHdlIHJlYWxseSBtZWFuIGhlcmUgPyANCg0KIA0KDQpUaGFua3MsIA0KDQpOYXRhcmFqdSBB IEINCg0KU29udXMgTmV0d29ya3MgSW5kaWEgUHZ0IEx0ZA0KDQo= ------_=_NextPart_001_01C6BF6B.AC1AB8A4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnN0MT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6c21hcnR0YWdzIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDExIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1l c3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBu YW1lPSJwbGFjZSIgZG93bmxvYWR1cmw9Imh0dHA6Ly93d3cuNWlhbnRsYXZhbGFtcC5jb20vIi8+ DQo8IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kc3QxXDoqe2JlaGF2aW9yOnVybCgjZGVmYXVsdCNp ZW9vdWkpIH0NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250 IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQXJpYWwgVW5pY29k ZSBNUyI7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiXEBBcmlhbCBVbmljb2RlIE1TIjsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIg MiAyIDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5U ZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLWNvbXBvc2U7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDc3Ljk1cHQgMS4waW4gNzcuOTVwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpT ZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQoNCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBs aW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFz cz1Nc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTAuMHB0Jz5IaSBTcGFya3MsIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPkkgaGFk IGdvbmUgdGhyb3VnaCB0aGUgZG9jdW1lbnQsIGhlcmUgYXJlIGZldyBjb21tZW50cy4gPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEwLjBwdCc+Tm90ZTogSSBhc3N1bWUgdGhlIGJlaGF2aW9yIG1lbnRpb25lZCBpbiBzZWMg NCBhcHBsaWVzIGJvdGggYXQgY2xpZW50DQpyZWNlaXZpbmcgdGhlc2UgcmVzcG9uc2VzIChOb3Rp ZmllcikgYW5kIHNlcnZlciBnZW5lcmF0aW5nIHRoZXNlIHJlcGxpZXMgKFN1YnNjcmliZXIpLg0K SWYgdGhpcyB3YXMgbWVhbnQgdG8gYmUgb25seSBAIHNlbmRlciBvZiBOT1RJRlkgc2hhbGwgd2Ug bmVlZCB0byBtZW50aW9uIHRoZSBzaW1pbGFyDQpzZXQgb2YgYWN0aW9ucyBAIFN1YnNjcmliZXIg c2lkZSB0b28/IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPjEuIFNlYyA0IGRlc2NyaWJlcyB3aGF0IHRoZSBl ZmZlY3RzIG9uIGRpYWxvZyBhcmUgYW5kIGl0cyB1c2FnZXMgd2hlbg0KcGFydGljdWxhciByZXNw b25zZXMgYXJlIHJlY2VpdmVkIGZvciBOT1RJRlkgbWVzc2FnZSwgdGhlIHJlc3BvbnNlcyA0MDQs IDQxMCwNCjQxNiwgbGVhZCB0byBkaWFsb2cgYW5kIGl0cyB1c2FnZSB0ZXJtaW5hdGlvbi4gPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBw dCc+wqDCoMKgwqDCoCBhLiBJIGZlZWwgd2Ugc2hvdWxkIGhhdmUgbWVudGlvbmVkIE9OTFkgdGhl IGF1dGhlbnRpY2F0ZWQgTk9USUZZDQpyZXF1ZXN0cyB3aWxsIGhhdmUgdGhpcyBlZmZlY3Qgb24g dGhlIGRpYWxvZ3MvdXNhZ2VzLiBPdGhlcndpc2UgYW55IG1pZGRsZSBtZW4NCmNhbiB0cmFjZSB0 aGUgbWVzc2FnZSBhbmQgc2VuZCB0aGUgTk9USUZZIG1lc3NhZ2VzIHdoaWNoIHRlcm1pbmF0ZSB0 aGUgZGlhbG9ncywNCndoaWNoIGlzIHVuZGVzaXJhYmxlIDwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFj ZT0iQXJpYWwgVW5pY29kZSBNUyI+PHNwYW4NCnN0eWxlPSdmb250LWZhbWlseToiQXJpYWwgVW5p Y29kZSBNUyInPuKYuTwvc3Bhbj48L2ZvbnQ+LiBJZiB0aGUgZW50aXR5IHNlbmRpbmcNCk5PVElG WSByZWFsbHkgaW50ZW5kIHRvIGRvIHRoYXQgaXQgY2FuIHJlc2VuZCBOT1RJRlkgd2l0aCBhdXRo b3JpemF0aW9uIGNyZWRlbnRpYWxzDQp3aGljaCB3aWxsIGhlbHAgdG8gdGVybWluYXRlIHRoZSBh c3NvY2lhdGVkIGRpYWxvZ3MuPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSdmb250LXNpemU6DQoxMC4wcHQnPsKgwqDCoMKgwqAgYi4gT3RoZXIgYWx0ZXJuYXRpdmUgd291 bGQgYmUgdGhhdCBsZXQgdGhvc2UgcmVzcG9uc2VzIGhhdmUgbm8NCmVmZmVjdCBvbiB0aGUgZGlh bG9nL3VzYWdlcywgZXZlbnR1YWxseSB0aGUgc3Vic2NyaXB0aW9uIGR1cmF0aW9uIHdvdWxkIHRh a2UNCmNhcmUgb2YgZGlhbG9nIHRlcm1pbmF0aW9uIG9yIHRoZSBhY3R1YWwgZW50aXR5IHdvdWxk IHRlcm1pbmF0ZSBvciBleHRlbmQgdGhlDQpzdWJzY3JpcHRpb24uIEFueSB3YXkgdGhlIHJlcXVl c3QgZnJvbSBhY3R1YWwgbm90aWZpZXIgd291bGQgaGF2ZSB0aGUgcHJvcGVyDQpVUklzIG9yIGNy ZWRlbnRpYWxzIHdoaWNoIHdpbGwgbmV2ZXIgbGVhZCB0byB0aGVzZSByZXNwb25zZXMuIDxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMC4wcHQnPlRoZSBzYW1lIGxvZ2ljIHdvdWxkIG5lZWQgdG8gZXh0ZW5kIGZvciByZXBs aWVzIDQ4MSwgNDgzLCA0ODQsIDxmb250DQpjb2xvcj1ibGFjaz48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjQ4OSBhbmQgNjA0IDwvc3Bhbj48L2ZvbnQ+YWxzby48bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0Jz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0Jz4y LiBTZWMgNCBvZiB0aGUgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTAuMHB0Jz7CoMKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPsKgwqDCoCAmbHQ7Jmx0OyZsdDvC oMKgIDQyMyBJbnRlcnZhbCBUb28gQnJpZWY6IFRoaXMgcmVzcG9uc2Ugd29uJ3QgaGFwcGVuDQpp biBvdXIgZXhhbXBsZTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdm b250LXNpemU6DQoxMC4wcHQnPsKgwqDCoMKgwqAgc2NlbmFyaW8sIGJ1dCBpZiBpdCBjYW1lIGlu IHJlc3BvbnNlIHRvIGEgcmVTVUJTQ1JJQkUsIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPsKgwqDCoMKgwqAgc3Vic2NyaWJl IHVzYWdlIGlzIG5vdCBkZXN0cm95ZWQgKG9yIG90aGVyd2lzZSBhZmZlY3RlZCkuwqAgTm88bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0 Jz7CoMKgwqDCoMKgIG90aGVyIHVzYWdlcyBvZiB0aGUgZGlhbG9nIGFyZSBhZmZlY3RlZC4gJmd0 OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdCc+wqDCoMKgwqDCoCBJbiB0aGUgYWJvdmUgPHN0MTpw bGFjZSB3OnN0PSJvbiI+UGFyYTwvc3QxOnBsYWNlPiB0aGUgbWVhbmluZyBvZg0KbGFzdCBwYXJ0 IG9mIDFzdCBzZW50ZW5jZSAoSSBtZWFuLCB0aGUgc3Vic2NyaWJlIHVzYWdlIGlzIG5vdCBkZXN0 cm95ZWQgKG9yDQpvdGhlcndpc2UgYWZmZWN0ZWQpKSBhbmQgMm5kIHNlbnRlbmNlIGlzIG5vdCBj bGVhciwgYm90aCBtZW50aW9uIHRoZSBzYW1lDQptZWFuaW5nPyBDYW4gd2UgbWFrZSBpdCBleHBs aWNpdCBhYm91dCB3aGF0IHdlIHJlYWxseSBtZWFuIGhlcmUgPyA8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0Jz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0Jz5U aGFua3MsIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMC4wcHQnPk5hdGFyYWp1IEEgQjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPlNvbnVzIE5ldHdvcmtzIEluZGlhIFB2dCBM dGQ8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8 L2h0bWw+DQo= ------_=_NextPart_001_01C6BF6B.AC1AB8A4-- --===============1251298182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============1251298182==-- From sip-bounces@ietf.org Mon Aug 14 02:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCWFG-0006wC-VU; Mon, 14 Aug 2006 02:48:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCWFF-0006w6-QW for sip@ietf.org; Mon, 14 Aug 2006 02:48:17 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCWFD-0002nS-Ug for sip@ietf.org; Mon, 14 Aug 2006 02:48:17 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C1B304F006A; Mon, 14 Aug 2006 08:48:12 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 08:48:12 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 08:48:12 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Mon, 14 Aug 2006 08:48:11 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1334@esealmw113.eemea.ericsson.se> In-Reply-To: <44DE7A94.6090802@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca+dHDByFtuaxTeTPOzWm2NdR88mwA+QbVg From: "Christer Holmberg \(JO/LMF\)" To: "Dean Willis" , "Cullen Jennings" X-OriginalArrivalTime: 14 Aug 2006 06:48:12.0287 (UTC) FILETIME=[9C6568F0:01C6BF6D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 4) If you get an indication in the REGISTER response that STUN keepalive is supported by the outbound proxy, you may start sending STUN requests. Regards, Christer =20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: 13. elokuuta 2006 4:04 To: Cullen Jennings Cc: sip@ietf.org; ft@it.su.se Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Cullen Jennings wrote: >=20 > On Aug 11, 2006, at 10:49 PM, =20 > wrote: >=20 >> >> The UA SHOULD add a Proxy-Require header field with the value=20 >> "sip-stun" to its REGISTER request. When the UA receives 200 OK with=20 >> Supported: Outbound it can be sure that the next hop will support=20 >> STUN keepalives. >> >> The proxy MUST remove the "sip-stun" value from the Proxy-Require=20 >> header field and then remove the header if no values remain before=20 >> forwarding the request to the next hop. >=20 > My mistake - it was some of the other stuff that was looking more=20 > complicated. I agree this is very easy implement. I also think Bob's=20 > proposal is very easy to implement - if the outbound proxy came from=20 > DHCP or was manually configured on the UA, then do an OPTIONS message=20 > first. Yay! How about we say: Either do 1 or 2 below, then always do 3: 1) Probe the proxy with OPTIONS to verify that it supports STUN or 2) Use a Proxy-Require as above and 3) if you don't get a STUN response, stop using STUN on this target (and I'd be happy to see this in STUN, not Outbound!) -- Dean _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 03:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCWUS-00055K-SN; Mon, 14 Aug 2006 03:04:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCWUR-000553-2d for sip@ietf.org; Mon, 14 Aug 2006 03:03:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCWUR-0004js-19 for sip@ietf.org; Mon, 14 Aug 2006 03:03:59 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCWR0-00081v-6T for sip@ietf.org; Mon, 14 Aug 2006 03:00:27 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id F2C773BEEA; Mon, 14 Aug 2006 09:00:16 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24638-02-32; Mon, 14 Aug 2006 09:00:16 +0200 (CEST) Received: from dhcp-wavelan-vo-32.publik.su.se (dhcp-wavelan-vo-32.publik.su.se [193.11.30.32]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 6C7D03BE67; Mon, 14 Aug 2006 09:00:12 +0200 (CEST) From: Fredrik Thulin To: "Christer Holmberg \(JO/LMF\)" Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Mon, 14 Aug 2006 08:59:05 +0200 User-Agent: KMail/1.9.3 References: <5EB80D22825EEE42872083AD5BFFB594017F1334@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1334@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608140859.05469.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.646 tagged_above=-99 required=7 tests=[AWL=0.019, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: -2.6 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Cullen Jennings , sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Monday 14 August 2006 08:48, Christer Holmberg (JO/LMF) wrote: > 4) If you get an indication in the REGISTER response that STUN > keepalive is supported by the outbound proxy, you may start sending > STUN requests. You won't get any STUN responses (Dean's no. 3) unless you send STUN requests. Do you, by the above, mean that if you get an indication in the REGISTER response from the outbound proxy that it supports STUN, then it is _always_ OK to periodically send STUN requests, even if no STUN response is received? This sounds odd, so please clarify. Did you perhaps mean to extend Dean's proposal into "do either 1, 2 or 4 and always do 3"? /Fredrik On Sunday 13 August 2006 03:04, Dean Willis wrote: ... > 3) if you don't get a STUN response, stop using STUN on this target > (and I'd be happy to see this in STUN, not Outbound!) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 03:05:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCWUd-00059r-0w; Mon, 14 Aug 2006 03:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCWUb-00058O-5W for sip@ietf.org; Mon, 14 Aug 2006 03:04:09 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCWUZ-0004kW-NM for sip@ietf.org; Mon, 14 Aug 2006 03:04:09 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 23A314F00A0; Mon, 14 Aug 2006 09:04:07 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 09:04:06 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 09:04: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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Mon, 14 Aug 2006 09:04:05 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1338@esealmw113.eemea.ericsson.se> In-Reply-To: <200608140859.05469.ft@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca/b07FjO2pIM43RSe/knG6CbLElAAABMiw From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" X-OriginalArrivalTime: 14 Aug 2006 07:04:06.0540 (UTC) FILETIME=[D52CDCC0:01C6BF6F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Cullen Jennings , sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>4) If you get an indication in the REGISTER response that STUN=20 >>keepalive is supported by the outbound proxy, you may start sending=20 >>STUN requests. >You won't get any STUN responses (Dean's no. 3) unless you send STUN requests.=20 I don't think I've said that... I am talking about the SIP REGISTER response. >Do you, by the above, mean that if you get an indication in the REGISTER response from the outbound proxy that it supports STUN, then it is _always_ OK=20 >to periodically send STUN requests, even if no STUN response is received? No, but if the UA gets an indication in the REGISTER response you can assume the outbund proxy supports STUN keepalive, and can start sending STUN towards the outbound proxy. But, of course, if it doesn't get a STUN response, it STOPS. Hopefully this clarifies. Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 03:15:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCWdm-0001Rs-OW; Mon, 14 Aug 2006 03:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCWdl-0001QL-A1 for sip@ietf.org; Mon, 14 Aug 2006 03:13:37 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCWdk-0005YM-1Y for sip@ietf.org; Mon, 14 Aug 2006 03:13:37 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 190AA740FD; Mon, 14 Aug 2006 09:13:35 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16472-01-13; Mon, 14 Aug 2006 09:13:34 +0200 (CEST) Received: from dhcp-wavelan-vo-32.publik.su.se (dhcp-wavelan-vo-32.publik.su.se [193.11.30.32]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 9FA31740FA; Mon, 14 Aug 2006 09:13:29 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 09:12:40 +0200 User-Agent: KMail/1.9.3 References: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> In-Reply-To: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608140912.40478.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.643 tagged_above=-99 required=7 tests=[AWL=0.022, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Monday 14 August 2006 00:57, Cullen Jennings wrote: > Hi, > > Rohan and I spent some time this afternoon trying to find a proposal > that makes more people happy than the other proposals mentioned about > STUN keepalive handling. ... This is fine, please finish the document. /Fredrik _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 03:44:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCX5Y-0004e7-VY; Mon, 14 Aug 2006 03:42:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCX5X-0004b0-7a for sip@ietf.org; Mon, 14 Aug 2006 03:42:19 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCX5U-0008Ma-Ig for sip@ietf.org; Mon, 14 Aug 2006 03:42:19 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D5B1B4F000D; Mon, 14 Aug 2006 09:42:15 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 09:42:15 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 09:42:15 +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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 Date: Mon, 14 Aug 2006 09:42:14 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1339@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 Thread-Index: Aca/LLSyZCxMJAt/T1u8jXMoKdgnggASB1ew From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" X-OriginalArrivalTime: 14 Aug 2006 07:42:15.0081 (UTC) FILETIME=[29408190:01C6BF75] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, Fredrik Thulin , rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>>MY problem is that I don't like to standardize behavior which is=20 >>>>based >>> >>>on sending something somewhere just to find out if the reciever=20 >>>supports the protocol in the first place. >>> >>>I will point out that when a UA is configured to send requests to >>>sip:example.com:5060 the way we find out if that port >>>on that machine supports SIP is by sending a SIP request to it. =20 >>>I'm not >>>sure I fully grasp the difference here. >> >>The difference is the following: >> >>If your UA is configured with a SIP address, the UA assumes SIP is=20 >>supported. >> >>But, if it is not possible to configure (e.g. If the UA only gets the=20 >>IP address of the outbound proxy) whether the outbound proxy supports=20 >>STUN or not, I think it's bad that the UA shall start sending STUN=20 >>requests in order to find out whether the outbound proxy supports STUN >>or not. >> >100% agree - I don't think the draft suggest this. I would be happy to add explicit text to the draft to say don't even think of doing something like=20 >this if that is causing confusion for people. I don't think the draft suggests it either, but I have heard proposals like that. Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 03:53:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCXEz-0008FX-4I; Mon, 14 Aug 2006 03:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCXEx-0008FQ-Bt for sip@ietf.org; Mon, 14 Aug 2006 03:52:03 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCXEv-00014o-Ex for sip@ietf.org; Mon, 14 Aug 2006 03:52:03 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 989A66E0001; Mon, 14 Aug 2006 09:52:00 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 09:52:00 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 09:52:00 +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 Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 09:51:59 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F133A@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1335@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound - a new STUN keealive proposal Thread-Index: Aca/LAeOlrCJwmvKT+mJrOfdN07rzAAPhv5AAALWC6A= From: "Christer Holmberg \(JO/LMF\)" To: "Christer Holmberg \(JO/LMF\)" , "Cullen Jennings" , "SIP" X-OriginalArrivalTime: 14 Aug 2006 07:52:00.0126 (UTC) FILETIME=[85F749E0:01C6BF76] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, One more thing: In another thread I proposed to, instead of using keepalive=3Dstun, we would use the same value as we use for the option-tag (e.g. sip-stun-keepalive). In the "[Sip] Outbound issues: slides 9 and 10" thread Rohan proposes an "ob" parameter to indicate support of Outbound, so why not simply use "sip-stun-keepalive" (or something similar) for STUN keepalive? The reason that the outbound proxy inserts "ob" is so that the registrar can verify that the outbound proxy supports Outbound.=20 Example: Path: sip:proxy@operator.com;ob;sip-stun-keepalive Regards, Christer =20 -----Original Message----- From: Christer Holmberg (JO/LMF)=20 Sent: 14. elokuuta 2006 9:50 To: 'Cullen Jennings'; SIP Cc: Rohan Mahy Subject: RE: [Sip] Outbound - a new STUN keealive proposal Hi Cullen and Rohan, Unfortunately I can't reply with any of the options (a,b,c or d). I do NOT object to your proposal. In fact, I think it looks very good, but I have a few questions: 1. Editorial: Shouldn't the stop-sending-STUN-requests-if-retransmissions-fail text (point 2) be in 3849bis? To me it sounds like generic STUN transaction procedures, which should be defined in the STUN spec. Or, do we consider it specific to the STUN keepalive usage for SIP??? 2. Functional: The proposal does not say anything about the outbound proxy being able to indicate STUN keepalive support, i.e. by inserting a keepalive=3Dstun (or something similar) in a Path/Service-Route header, and/or the option tag in the Supported header (if the outbound proxy happens to also be the registrar), or the REGISTER, as has been discussed in a separate thread (I think we also agreed to keep it within the scope). I think it would be very useful, especially in cases where the UA does not have any "explicit indication" beforehand, and where the UA does not want to send OPTIONS before sending REGISTER (e.g. due to the fact that the UA would continue the registration no matter if the outbound proxy supports STUN keepalive or not). 3. Editorial: Would it be possible to name the option tag "sip-stun-keepalive", instead of just "sip-stun"? Or, are we sure we will never have to be able to indicate any other type of STUN usage support for SIP? Regards, Christer =20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: 14. elokuuta 2006 1:58 To: SIP Cc: Rohan Mahy Subject: [Sip] Outbound - a new STUN keealive proposal Hi, Rohan and I spent some time this afternoon trying to find a proposal that makes more people happy than the other proposals mentioned about STUN keepalive handling. We did this because some people expressed concern or displeasure about one proposal or another, but keep in mind that both of us are fine with the draft as is, in regards to this topic. What we are proposing is the following: 1) We already agreed to move the STUN keepalive definition to a separate section. This makes it clear how to use STUN keepalives even for implementations that do not use the rest of outbound. This is agreed - we are doing it, just listing it here for completeness. 2) Following the basic principle of "do no harm", we propose adding text to tell UAs that if an initial STUN request and its retransmissions fail, the UA MUST stop sending STUN requests to this destination. The details of how to specify this will be difficult to articulate succinctly, but we'd like to get agreement to this idea in principle. The difficulty is that if a flow fails completely, this is not necessarily indicative that the server has forgotten how to do STUN. 3) In the same vein, we propose adding text to make it clearer that a UA MUST NOT send STUN requests unless it has an explicit indication that the target SIP server supports STUN. We can further clarify that UA implementations should not have an ambiguous manual configuration option such as a "Work with NATs?" checkbox that would cause STUN keepalives to be used blindly. Manual configuration of an outbound URI that includes the ";keealive=3Dstun" parameter is considered an explicit indication. Now on to the new part of the proposal... 4) In the STUN keepalive section of the document, define a "sip-stun" =20 option-tag and describe its semantics (this server can receive STUN messages and SIP messages on the same port). Describe that an OPTIONS message MAY be used to probe or verify if a specific server supports sip-stun. Future specifications can define other uses of this option- tag. This leaves our options open as a WG. 5) In the outbound portion of the draft, make it clear that the first- hop proxy MUST support the "sip-stun" option-tag. (If the UA probes the first-hop, the probe needs to succeed). 6) Also in the outbound section of the draft, explain that that it is NOT RECOMMENDED for a UAC to include a Proxy-Require header field with the sip-stun option-tag. This is because the request would fail in some topologies where the first proxy supports sip-stun but subsequent proxies do not. Remind implementors that RFC 3261 does not allow proxies to remove option-tags from a Proxy-Require header field. To summarize this proposal: - It does no harm: It insures STUN is only used when explicitly configured and provides supportive implementation guidance, and it stops sending STUN if the server does not respond to initial STUN traffic. - It leaves our options open, while allowing outbound to progress: =20 It keeps the door open for future explicit discovery mechanisms, and allows other potential uses of STUN keepalives. - It works. Please reply to the list or to (the chairs and authors) with one of the following choices: a) This is fine/good/OK b) I can live with this proposal, but prefer omitting the "sip-stun" =20 option-tag c) I object (please provide reasons) d) I don't care, just please finish the document Thanks, Cullen & Rohan _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 04:26:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCXkD-0006Nn-Vc; Mon, 14 Aug 2006 04:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCXkC-0006Ni-Kg for sip@ietf.org; Mon, 14 Aug 2006 04:24:20 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCXkB-0005np-0P for sip@ietf.org; Mon, 14 Aug 2006 04:24:20 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7E8O6Ou022382; Mon, 14 Aug 2006 11:24:10 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 11:24:09 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 11:24:08 +0300 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 Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 11:24:07 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F029A60C4@esebe103.NOE.Nokia.com> In-Reply-To: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound - a new STUN keealive proposal Thread-Index: Aca/LCTKoGIS7CuHTgaenmmKm4H5PgAS41gA From: To: , X-OriginalArrivalTime: 14 Aug 2006 08:24:08.0629 (UTC) FILETIME=[03717E50:01C6BF7B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I was very happy to see this proposal from Cullen and agree=20 with it - apart from one single item, which I still disagree: >6) Also in the outbound section of the draft, explain that that it is =20 >NOT RECOMMENDED for a UAC to include a Proxy-Require header field =20 >with the sip-stun option-tag. This is because the request would fail =20 >in some topologies where the first proxy supports sip-stun but =20 >subsequent proxies do not. Remind implementors that RFC 3261 does not =20 >allow proxies to remove option-tags from a Proxy-Require header field. The reasons for my disagreement are expressed in this email from Jonathan, from a thread related to RFC 3329: http://www1.ietf.org/mail-archive/web/sip/current/msg07871.html Jonathan says: > Interestingly, RFC3329 is not the first RFC to have a proxy=20 > remove a proxy-require header. RFC 3323 (Privacy extensions)=20 > does the same thing for much the same reason. As such, I agree=20 > that this is probably a bug in RFC3261. > > I've logged the bug into bugzilla: > http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D707 Further on the submitted proposal is incomplete in the sense that it does not specify how the compliant proxy must react to a request which would contain sip-stun option tag in Proxy-Require header. The proposed text is just a recommendation so that a compliant UA implementation might still use that tag in Proxy-Require header. The results for doing that must be deterministic even if the UA would be preferred to send OPTIONS instead. I propose this item 6 to be removed from the proposal and=20 the text I proposed earlier to be added to the draft: > The UA MAY add a Proxy-Require header field with the > value "sip-stun" to its REGISTER request. When the UA > thereafter receives 200 OK with Supported: Outbound it=20 > can be sure that the next hop will support STUN keepalives. > > The proxy MUST remove the "sip-stun" value from the > Proxy-Require header field and then remove the header > if no values remain before forwarding the request to > the next hop. Regards, Erkki=20 >-----Original Message----- >From: ext Cullen Jennings [mailto:fluffy@cisco.com]=20 >Sent: 14.August.2006 01:58 >To: SIP >Cc: Rohan Mahy >Subject: [Sip] Outbound - a new STUN keealive proposal > >Hi, > >Rohan and I spent some time this afternoon trying to find a proposal =20 >that makes more people happy than the other proposals mentioned about =20 >STUN keepalive handling. We did this because some people expressed =20 >concern or displeasure about one proposal or another, but keep in =20 >mind that both of us are fine with the draft as is, in regards to =20 >this topic. > >What we are proposing is the following: > >1) We already agreed to move the STUN keepalive definition to a =20 >separate section. This makes it clear how to use STUN keepalives =20 >even for implementations that do not use the rest of outbound. This =20 >is agreed - we are doing it, just listing it here for completeness. > >2) Following the basic principle of "do no harm", we propose adding =20 >text to tell UAs that if an initial STUN request and its =20 >retransmissions fail, the UA MUST stop sending STUN requests to this =20 >destination. The details of how to specify this will be difficult to =20 >articulate succinctly, but we'd like to get agreement to this idea in =20 >principle. The difficulty is that if a flow fails completely, this =20 >is not necessarily indicative that the server has forgotten how to do =20 >STUN. > >3) In the same vein, we propose adding text to make it clearer that a =20 >UA MUST NOT send STUN requests unless it has an explicit indication =20 >that the target SIP server supports STUN. We can further clarify that =20 >UA implementations should not have an ambiguous manual configuration =20 >option such as a "Work with NATs?" checkbox that would cause STUN =20 >keepalives to be used blindly. Manual configuration of an outbound =20 >URI that includes the ";keealive=3Dstun" parameter is considered an =20 >explicit indication. > >Now on to the new part of the proposal... > >4) In the STUN keepalive section of the document, define a "sip-stun" =20 >option-tag and describe its semantics (this server can receive STUN =20 >messages and SIP messages on the same port). Describe that an OPTIONS =20 >message MAY be used to probe or verify if a specific server supports =20 >sip-stun. Future specifications can define other uses of this option-=20 >tag. This leaves our options open as a WG. > >5) In the outbound portion of the draft, make it clear that the first-=20 >hop proxy MUST support the "sip-stun" option-tag. (If the UA probes =20 >the first-hop, the probe needs to succeed). > >6) Also in the outbound section of the draft, explain that that it is =20 >NOT RECOMMENDED for a UAC to include a Proxy-Require header field =20 >with the sip-stun option-tag. This is because the request would fail =20 >in some topologies where the first proxy supports sip-stun but =20 >subsequent proxies do not. Remind implementors that RFC 3261 does not =20 >allow proxies to remove option-tags from a Proxy-Require header field. > >To summarize this proposal: >- It does no harm: It insures STUN is only used when explicitly =20 >configured and provides supportive implementation guidance, and it =20 >stops sending STUN if the server does not respond to initial STUN =20 >traffic. >- It leaves our options open, while allowing outbound to progress: =20 >It keeps the door open for future explicit discovery mechanisms, and =20 >allows other potential uses of STUN keepalives. >- It works. > >Please reply to the list or to (the chairs and authors) with one of =20 >the following choices: >a) This is fine/good/OK >b) I can live with this proposal, but prefer omitting the "sip-stun" =20 >option-tag >c) I object (please provide reasons) >d) I don't care, just please finish the document > >Thanks, Cullen & Rohan > >_______________________________________________ >Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 04:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCY2Z-0005bn-Lh; Mon, 14 Aug 2006 04:43:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCY2Y-0005bf-25 for sip@ietf.org; Mon, 14 Aug 2006 04:43:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCWUS-0004js-Hd for sip@ietf.org; Mon, 14 Aug 2006 03:04:00 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCWHC-0007tm-Tq for sip@ietf.org; Mon, 14 Aug 2006 02:50:21 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BDD264F006A; Mon, 14 Aug 2006 08:49:57 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 08:49:56 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 08:49:56 +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 Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 08:49:56 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1335@esealmw113.eemea.ericsson.se> In-Reply-To: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound - a new STUN keealive proposal Thread-Index: Aca/LAeOlrCJwmvKT+mJrOfdN07rzAAPhv5A From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "SIP" X-OriginalArrivalTime: 14 Aug 2006 06:49:56.0708 (UTC) FILETIME=[DAA2CA40:01C6BF6D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Cullen and Rohan, Unfortunately I can't reply with any of the options (a,b,c or d). I do NOT object to your proposal. In fact, I think it looks very good, but I have a few questions: 1. Editorial: Shouldn't the stop-sending-STUN-requests-if-retransmissions-fail text (point 2) be in 3849bis? To me it sounds like generic STUN transaction procedures, which should be defined in the STUN spec. Or, do we consider it specific to the STUN keepalive usage for SIP??? 2. Functional: The proposal does not say anything about the outbound proxy being able to indicate STUN keepalive support, i.e. by inserting a keepalive=3Dstun (or something similar) in a Path/Service-Route header, and/or the option tag in the Supported header (if the outbound proxy happens to also be the registrar), or the REGISTER, as has been discussed in a separate thread (I think we also agreed to keep it within the scope). I think it would be very useful, especially in cases where the UA does not have any "explicit indication" beforehand, and where the UA does not want to send OPTIONS before sending REGISTER (e.g. due to the fact that the UA would continue the registration no matter if the outbound proxy supports STUN keepalive or not). 3. Editorial: Would it be possible to name the option tag "sip-stun-keepalive", instead of just "sip-stun"? Or, are we sure we will never have to be able to indicate any other type of STUN usage support for SIP? Regards, Christer =20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: 14. elokuuta 2006 1:58 To: SIP Cc: Rohan Mahy Subject: [Sip] Outbound - a new STUN keealive proposal Hi, Rohan and I spent some time this afternoon trying to find a proposal that makes more people happy than the other proposals mentioned about STUN keepalive handling. We did this because some people expressed concern or displeasure about one proposal or another, but keep in mind that both of us are fine with the draft as is, in regards to this topic. What we are proposing is the following: 1) We already agreed to move the STUN keepalive definition to a separate section. This makes it clear how to use STUN keepalives even for implementations that do not use the rest of outbound. This is agreed - we are doing it, just listing it here for completeness. 2) Following the basic principle of "do no harm", we propose adding text to tell UAs that if an initial STUN request and its retransmissions fail, the UA MUST stop sending STUN requests to this destination. The details of how to specify this will be difficult to articulate succinctly, but we'd like to get agreement to this idea in principle. The difficulty is that if a flow fails completely, this is not necessarily indicative that the server has forgotten how to do STUN. 3) In the same vein, we propose adding text to make it clearer that a UA MUST NOT send STUN requests unless it has an explicit indication that the target SIP server supports STUN. We can further clarify that UA implementations should not have an ambiguous manual configuration option such as a "Work with NATs?" checkbox that would cause STUN keepalives to be used blindly. Manual configuration of an outbound URI that includes the ";keealive=3Dstun" parameter is considered an explicit indication. Now on to the new part of the proposal... 4) In the STUN keepalive section of the document, define a "sip-stun" =20 option-tag and describe its semantics (this server can receive STUN messages and SIP messages on the same port). Describe that an OPTIONS message MAY be used to probe or verify if a specific server supports sip-stun. Future specifications can define other uses of this option- tag. This leaves our options open as a WG. 5) In the outbound portion of the draft, make it clear that the first- hop proxy MUST support the "sip-stun" option-tag. (If the UA probes the first-hop, the probe needs to succeed). 6) Also in the outbound section of the draft, explain that that it is NOT RECOMMENDED for a UAC to include a Proxy-Require header field with the sip-stun option-tag. This is because the request would fail in some topologies where the first proxy supports sip-stun but subsequent proxies do not. Remind implementors that RFC 3261 does not allow proxies to remove option-tags from a Proxy-Require header field. To summarize this proposal: - It does no harm: It insures STUN is only used when explicitly configured and provides supportive implementation guidance, and it stops sending STUN if the server does not respond to initial STUN traffic. - It leaves our options open, while allowing outbound to progress: =20 It keeps the door open for future explicit discovery mechanisms, and allows other potential uses of STUN keepalives. - It works. Please reply to the list or to (the chairs and authors) with one of the following choices: a) This is fine/good/OK b) I can live with this proposal, but prefer omitting the "sip-stun" =20 option-tag c) I object (please provide reasons) d) I don't care, just please finish the document Thanks, Cullen & Rohan _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 05:39:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCYtb-0002tA-1o; Mon, 14 Aug 2006 05:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCYtY-0002t0-S9 for sip@ietf.org; Mon, 14 Aug 2006 05:38:04 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCYtY-0004g6-BJ for sip@ietf.org; Mon, 14 Aug 2006 05:38:04 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id B9E2D20A309; Mon, 14 Aug 2006 09:37:31 +0000 (UTC) Message-Id: <7.0.1.0.0.20060814112004.029275e0@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 14 Aug 2006 11:23:07 +0200 To: Cullen Jennings , SIP From: Jiri Kuthan Subject: Re: [Sip] Outbound - a new STUN keealive proposal In-Reply-To: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> References: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Cullen, I think we should actually step back and seek what level of applicability are we seeking. Is STUN/keepalives a SIP thing for sip-wg or is it perhaps a general application guideline for behave? also regarding 3 -- I think if we consider saying MUST NOT, we should include WHY. -jiri At 00:57 14/08/2006, Cullen Jennings wrote: >Hi, > >Rohan and I spent some time this afternoon trying to find a proposal >that makes more people happy than the other proposals mentioned about >STUN keepalive handling. We did this because some people expressed >concern or displeasure about one proposal or another, but keep in >mind that both of us are fine with the draft as is, in regards to >this topic. > >What we are proposing is the following: > >1) We already agreed to move the STUN keepalive definition to a >separate section. This makes it clear how to use STUN keepalives >even for implementations that do not use the rest of outbound. This >is agreed - we are doing it, just listing it here for completeness. > >2) Following the basic principle of "do no harm", we propose adding >text to tell UAs that if an initial STUN request and its >retransmissions fail, the UA MUST stop sending STUN requests to this >destination. The details of how to specify this will be difficult to >articulate succinctly, but we'd like to get agreement to this idea in >principle. The difficulty is that if a flow fails completely, this >is not necessarily indicative that the server has forgotten how to do >STUN. > >3) In the same vein, we propose adding text to make it clearer that a >UA MUST NOT send STUN requests unless it has an explicit indication >that the target SIP server supports STUN. We can further clarify that >UA implementations should not have an ambiguous manual configuration >option such as a "Work with NATs?" checkbox that would cause STUN >keepalives to be used blindly. Manual configuration of an outbound >URI that includes the ";keealive=stun" parameter is considered an >explicit indication. > >Now on to the new part of the proposal... > >4) In the STUN keepalive section of the document, define a "sip-stun" >option-tag and describe its semantics (this server can receive STUN >messages and SIP messages on the same port). Describe that an OPTIONS >message MAY be used to probe or verify if a specific server supports >sip-stun. Future specifications can define other uses of this option- tag. This leaves our options open as a WG. > >5) In the outbound portion of the draft, make it clear that the first- hop proxy MUST support the "sip-stun" option-tag. (If the UA probes >the first-hop, the probe needs to succeed). > >6) Also in the outbound section of the draft, explain that that it is >NOT RECOMMENDED for a UAC to include a Proxy-Require header field >with the sip-stun option-tag. This is because the request would fail >in some topologies where the first proxy supports sip-stun but >subsequent proxies do not. Remind implementors that RFC 3261 does not >allow proxies to remove option-tags from a Proxy-Require header field. > >To summarize this proposal: >- It does no harm: It insures STUN is only used when explicitly >configured and provides supportive implementation guidance, and it >stops sending STUN if the server does not respond to initial STUN >traffic. >- It leaves our options open, while allowing outbound to progress: >It keeps the door open for future explicit discovery mechanisms, and >allows other potential uses of STUN keepalives. >- It works. > >Please reply to the list or to (the chairs and authors) with one of >the following choices: >a) This is fine/good/OK >b) I can live with this proposal, but prefer omitting the "sip-stun" >option-tag >c) I object (please provide reasons) >d) I don't care, just please finish the document > >Thanks, Cullen & Rohan > >_______________________________________________ >Sip mailing list https://www1.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 -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 05:39:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCYtb-0002tl-OB; Mon, 14 Aug 2006 05:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCYtZ-0002t5-Lk for sip@ietf.org; Mon, 14 Aug 2006 05:38:05 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCYtY-0004g7-BJ for sip@ietf.org; Mon, 14 Aug 2006 05:38:05 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id C765120A30C; Mon, 14 Aug 2006 09:37:32 +0000 (UTC) Message-Id: <7.0.1.0.0.20060814112323.05776ec0@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 14 Aug 2006 11:23:32 +0200 To: Cullen Jennings , Christer Holmberg ((JO/LMF)) From: Jiri Kuthan Subject: Re: [Sip] Outbound Issues: slides 3 and 4 In-Reply-To: References: <5EB80D22825EEE42872083AD5BFFB594017F1332@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, rohan@ekabal.com, Fredrik Thulin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 01:03 14/08/2006, Cullen Jennings wrote: >On Aug 13, 2006, at 3:32 AM, Christer Holmberg ((JO/LMF)) wrote: > >> >>Hi, >> >>>>MY problem is that I don't like to standardize behavior which is >>>>based >> >>>>on sending something somewhere just to find out if the reciever >>>>supports the protocol in the first place. >>> >>>I will point out that when a UA is configured to send requests to >>sip:example.com:5060 the way we find out if that port >>>on that machine supports SIP is by sending a SIP request to it. >>>I'm not >>sure I fully grasp the difference here. >> >>The difference is the following: >> >>If your UA is configured with a SIP address, the UA assumes SIP is >>supported. >> >>But, if it is not possible to configure (e.g. If the UA only gets >>the IP >>address of the outbound proxy) whether the outbound proxy supports >>STUN >>or not, I think it's bad that the UA shall start sending STUN requests >>in order to find out whether the outbound proxy supports STUN or not. > >100% agree - I don't think the draft suggest this. I would be happy >to add explicit text to the draft to say don't even think of doing >something like this if that is causing confusion for people. why? -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 05:39:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCYtb-0002tA-1o; Mon, 14 Aug 2006 05:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCYtY-0002t0-S9 for sip@ietf.org; Mon, 14 Aug 2006 05:38:04 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCYtY-0004g6-BJ for sip@ietf.org; Mon, 14 Aug 2006 05:38:04 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id B9E2D20A309; Mon, 14 Aug 2006 09:37:31 +0000 (UTC) Message-Id: <7.0.1.0.0.20060814112004.029275e0@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 14 Aug 2006 11:23:07 +0200 To: Cullen Jennings , SIP From: Jiri Kuthan Subject: Re: [Sip] Outbound - a new STUN keealive proposal In-Reply-To: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> References: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Cullen, I think we should actually step back and seek what level of applicability are we seeking. Is STUN/keepalives a SIP thing for sip-wg or is it perhaps a general application guideline for behave? also regarding 3 -- I think if we consider saying MUST NOT, we should include WHY. -jiri At 00:57 14/08/2006, Cullen Jennings wrote: >Hi, > >Rohan and I spent some time this afternoon trying to find a proposal >that makes more people happy than the other proposals mentioned about >STUN keepalive handling. We did this because some people expressed >concern or displeasure about one proposal or another, but keep in >mind that both of us are fine with the draft as is, in regards to >this topic. > >What we are proposing is the following: > >1) We already agreed to move the STUN keepalive definition to a >separate section. This makes it clear how to use STUN keepalives >even for implementations that do not use the rest of outbound. This >is agreed - we are doing it, just listing it here for completeness. > >2) Following the basic principle of "do no harm", we propose adding >text to tell UAs that if an initial STUN request and its >retransmissions fail, the UA MUST stop sending STUN requests to this >destination. The details of how to specify this will be difficult to >articulate succinctly, but we'd like to get agreement to this idea in >principle. The difficulty is that if a flow fails completely, this >is not necessarily indicative that the server has forgotten how to do >STUN. > >3) In the same vein, we propose adding text to make it clearer that a >UA MUST NOT send STUN requests unless it has an explicit indication >that the target SIP server supports STUN. We can further clarify that >UA implementations should not have an ambiguous manual configuration >option such as a "Work with NATs?" checkbox that would cause STUN >keepalives to be used blindly. Manual configuration of an outbound >URI that includes the ";keealive=stun" parameter is considered an >explicit indication. > >Now on to the new part of the proposal... > >4) In the STUN keepalive section of the document, define a "sip-stun" >option-tag and describe its semantics (this server can receive STUN >messages and SIP messages on the same port). Describe that an OPTIONS >message MAY be used to probe or verify if a specific server supports >sip-stun. Future specifications can define other uses of this option- tag. This leaves our options open as a WG. > >5) In the outbound portion of the draft, make it clear that the first- hop proxy MUST support the "sip-stun" option-tag. (If the UA probes >the first-hop, the probe needs to succeed). > >6) Also in the outbound section of the draft, explain that that it is >NOT RECOMMENDED for a UAC to include a Proxy-Require header field >with the sip-stun option-tag. This is because the request would fail >in some topologies where the first proxy supports sip-stun but >subsequent proxies do not. Remind implementors that RFC 3261 does not >allow proxies to remove option-tags from a Proxy-Require header field. > >To summarize this proposal: >- It does no harm: It insures STUN is only used when explicitly >configured and provides supportive implementation guidance, and it >stops sending STUN if the server does not respond to initial STUN >traffic. >- It leaves our options open, while allowing outbound to progress: >It keeps the door open for future explicit discovery mechanisms, and >allows other potential uses of STUN keepalives. >- It works. > >Please reply to the list or to (the chairs and authors) with one of >the following choices: >a) This is fine/good/OK >b) I can live with this proposal, but prefer omitting the "sip-stun" >option-tag >c) I object (please provide reasons) >d) I don't care, just please finish the document > >Thanks, Cullen & Rohan > >_______________________________________________ >Sip mailing list https://www1.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 -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 05:39:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCYtb-0002tl-OB; Mon, 14 Aug 2006 05:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCYtZ-0002t5-Lk for sip@ietf.org; Mon, 14 Aug 2006 05:38:05 -0400 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCYtY-0004g7-BJ for sip@ietf.org; Mon, 14 Aug 2006 05:38:05 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id C765120A30C; Mon, 14 Aug 2006 09:37:32 +0000 (UTC) Message-Id: <7.0.1.0.0.20060814112323.05776ec0@iptel.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 14 Aug 2006 11:23:32 +0200 To: Cullen Jennings , Christer Holmberg ((JO/LMF)) From: Jiri Kuthan Subject: Re: [Sip] Outbound Issues: slides 3 and 4 In-Reply-To: References: <5EB80D22825EEE42872083AD5BFFB594017F1332@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, rohan@ekabal.com, Fredrik Thulin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 01:03 14/08/2006, Cullen Jennings wrote: >On Aug 13, 2006, at 3:32 AM, Christer Holmberg ((JO/LMF)) wrote: > >> >>Hi, >> >>>>MY problem is that I don't like to standardize behavior which is >>>>based >> >>>>on sending something somewhere just to find out if the reciever >>>>supports the protocol in the first place. >>> >>>I will point out that when a UA is configured to send requests to >>sip:example.com:5060 the way we find out if that port >>>on that machine supports SIP is by sending a SIP request to it. >>>I'm not >>sure I fully grasp the difference here. >> >>The difference is the following: >> >>If your UA is configured with a SIP address, the UA assumes SIP is >>supported. >> >>But, if it is not possible to configure (e.g. If the UA only gets >>the IP >>address of the outbound proxy) whether the outbound proxy supports >>STUN >>or not, I think it's bad that the UA shall start sending STUN requests >>in order to find out whether the outbound proxy supports STUN or not. > >100% agree - I don't think the draft suggest this. I would be happy >to add explicit text to the draft to say don't even think of doing >something like this if that is causing confusion for people. why? -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 05:54:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZ7d-0001TB-Gt; Mon, 14 Aug 2006 05:52:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZ7b-0001NK-Cv for sip@ietf.org; Mon, 14 Aug 2006 05:52:35 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCZ7Z-0006wB-Tj for sip@ietf.org; Mon, 14 Aug 2006 05:52:35 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 2F7E1194546 for ; Mon, 14 Aug 2006 11:52:33 +0200 (CEST) Received: from [192.168.1.39] ([192.168.1.39]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 11:52:33 +0200 In-Reply-To: <44DE7A94.6090802@softarmor.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F029A5E2A@esebe103.NOE.Nokia.com> <9435CA97-BD83-4678-8A8A-46239090B6B6@cisco.com> <44DE7A94.6090802@softarmor.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Mon, 14 Aug 2006 11:53:07 +0200 To: Dean Willis X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 14 Aug 2006 09:52:33.0126 (UTC) FILETIME=[5D2B8060:01C6BF87] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Cullen Jennings , sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Why not just do 3? If 1 or 2 doesn't give you that guarantee and you still need to build into your client an error handling code, you might as well just do 3 by itself. Hisham On Aug 13, 2006, at 3:04 AM, Dean Willis wrote: > Cullen Jennings wrote: >> On Aug 11, 2006, at 10:49 PM, >> wrote: >>> >>> The UA SHOULD add a Proxy-Require header field with the >>> value "sip-stun" to its REGISTER request. When the UA >>> receives 200 OK with Supported: Outbound it can be sure >>> that the next hop will support STUN keepalives. >>> >>> The proxy MUST remove the "sip-stun" value from the >>> Proxy-Require header field and then remove the header >>> if no values remain before forwarding the request to >>> the next hop. >> My mistake - it was some of the other stuff that was looking more >> complicated. I agree this is very easy implement. I also think Bob's >> proposal is very easy to implement - if the outbound proxy came from >> DHCP or was manually configured on the UA, then do an OPTIONS message >> first. > > > Yay! > > > How about we say: > > Either do 1 or 2 below, then always do 3: > > 1) Probe the proxy with OPTIONS to verify that it supports STUN > > or > > 2) Use a Proxy-Require as above > > and > > 3) if you don't get a STUN response, stop using STUN on this target > (and I'd be happy to see this in STUN, not Outbound!) > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 06:13:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZQE-0001yV-Ug; Mon, 14 Aug 2006 06:11:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZQC-0001yH-Sv for sip@ietf.org; Mon, 14 Aug 2006 06:11:48 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCZQB-0002fT-A8 for sip@ietf.org; Mon, 14 Aug 2006 06:11:48 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 6050C194534 for ; Mon, 14 Aug 2006 12:11:46 +0200 (CEST) Received: from [192.168.1.39] ([192.168.1.39]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 12:11:46 +0200 In-Reply-To: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> References: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3acf2324644868f606601d28443b31b3@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 12:12:20 +0200 To: Cullen Jennings X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 14 Aug 2006 10:11:46.0339 (UTC) FILETIME=[0C89D730:01C6BF8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: SIP , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think we should say the following: A UA MAY do *either or both* of the following, *in any order*, in order to verify that an outbound proxy supports stun keepalive, IF the UA is configured to say that outbound proxy supports stun - send stun requests including retransmissions - send SIP OPTIONS request Implementers can choose the order they want. It can even be configurable where the service provider can configure the order. I also want to point out that the UA needs to try again after some units of time if stun fails, if the UA is configured to say that outbound proxy supports stun. The reason is that I might have upgraded my server to a bad version where the stun part was buggy. I don't want to ask my customers to reboot their UA in order to get stun to work again from the UA. Hisham On Aug 14, 2006, at 12:57 AM, Cullen Jennings wrote: > Hi, > > Rohan and I spent some time this afternoon trying to find a proposal > that makes more people happy than the other proposals mentioned about > STUN keepalive handling. We did this because some people expressed > concern or displeasure about one proposal or another, but keep in mind > that both of us are fine with the draft as is, in regards to this > topic. > > What we are proposing is the following: > > 1) We already agreed to move the STUN keepalive definition to a > separate section. This makes it clear how to use STUN keepalives even > for implementations that do not use the rest of outbound. This is > agreed - we are doing it, just listing it here for completeness. > > 2) Following the basic principle of "do no harm", we propose adding > text to tell UAs that if an initial STUN request and its > retransmissions fail, the UA MUST stop sending STUN requests to this > destination. The details of how to specify this will be difficult to > articulate succinctly, but we'd like to get agreement to this idea in > principle. The difficulty is that if a flow fails completely, this is > not necessarily indicative that the server has forgotten how to do > STUN. > > 3) In the same vein, we propose adding text to make it clearer that a > UA MUST NOT send STUN requests unless it has an explicit indication > that the target SIP server supports STUN. We can further clarify that > UA implementations should not have an ambiguous manual configuration > option such as a "Work with NATs?" checkbox that would cause STUN > keepalives to be used blindly. Manual configuration of an outbound URI > that includes the ";keealive=stun" parameter is considered an explicit > indication. > > Now on to the new part of the proposal... > > 4) In the STUN keepalive section of the document, define a "sip-stun" > option-tag and describe its semantics (this server can receive STUN > messages and SIP messages on the same port). Describe that an OPTIONS > message MAY be used to probe or verify if a specific server supports > sip-stun. Future specifications can define other uses of this > option-tag. This leaves our options open as a WG. > > 5) In the outbound portion of the draft, make it clear that the > first-hop proxy MUST support the "sip-stun" option-tag. (If the UA > probes the first-hop, the probe needs to succeed). > > 6) Also in the outbound section of the draft, explain that that it is > NOT RECOMMENDED for a UAC to include a Proxy-Require header field with > the sip-stun option-tag. This is because the request would fail in > some topologies where the first proxy supports sip-stun but subsequent > proxies do not. Remind implementors that RFC 3261 does not allow > proxies to remove option-tags from a Proxy-Require header field. > > To summarize this proposal: > - It does no harm: It insures STUN is only used when explicitly > configured and provides supportive implementation guidance, and it > stops sending STUN if the server does not respond to initial STUN > traffic. > - It leaves our options open, while allowing outbound to progress: It > keeps the door open for future explicit discovery mechanisms, and > allows other potential uses of STUN keepalives. > - It works. > > Please reply to the list or to (the chairs and authors) with one of > the following choices: > a) This is fine/good/OK > b) I can live with this proposal, but prefer omitting the "sip-stun" > option-tag > c) I object (please provide reasons) > d) I don't care, just please finish the document > > Thanks, Cullen & Rohan > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 06:41:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZr2-0005sK-5n; Mon, 14 Aug 2006 06:39:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZr0-0005s4-Mv for sip@ietf.org; Mon, 14 Aug 2006 06:39:30 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCZqx-0006hc-Od for sip@ietf.org; Mon, 14 Aug 2006 06:39:30 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DE21F8E0001; Mon, 14 Aug 2006 12:39:26 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 12:39:25 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 12:39: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 Subject: RE: [Sip] Outbound issues: slides 9 and 10 - Why does every proxyneed to support outbound? Date: Mon, 14 Aug 2006 12:39:25 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F133F@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound issues: slides 9 and 10 - Why does every proxyneed to support outbound? Thread-Index: Aca8jT4lem/BN+7DRkaVAjSm9Rr8igDAGg5g From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 14 Aug 2006 10:39:25.0861 (UTC) FILETIME=[E9B0CD50:01C6BF8D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan,=20 >>>Christer, please read the slides. The issue we are trying to detect=20 >>>is described in slide 9. The UA sends through an >>>outbound-proxy that adds a Path, but does not support outbound. The >>>registrar needs to detect that. >> >>I am not arguing against that. I am simply commenting on the proposed=20 >>mechanisms that YOU wrote. >> >>YOU said that ALL Path headers (not only the one inserted by the=20 >>outbound proxy) must contain the ob parameter, and I question that. >> >>YOU said that the registrar must start comparing Vias with Paths, and=20 >>I propose a way to avoid that. > >Right. You should be able to compare only the first Path and the first Via. I guess there is no reason for the other Path headers to have ;ob. Wouldn't it be easier, and "cleaner", to say that the outbound proxy MUST always (no matter what domain it belongs to) Path with "ob"? Regards, Christer > On Aug 9, 2006, at 9:46, Christer Holmberg ((JO/LMF)) wrote: >> >> Hi, >> >> A couple of questions: >> >>> The issues on slide 9 (how does a registrar verify that an edge=20 >>> proxy >> supports outbound) and slide 10 (what does >"Supported: outbound" >> mean) deal with detecting that all the required hops support outbound. > >> Slide >>> 9 specifically uncovered a problem with outbound proxies that add a >> Path URI but don't include a flow token. >>> >>> The proposed solution is as follows. If a proxy inserts a Path=20 >>> header >> with a flow token consistent with the rules d >>> escribed in outbound, it MUST add the ;ob parameter to the proxy URI >> that has the flow token. >>> >>> The registrar verifies that any Path header URIs contain the ;ob >> parameter. If there are any Path URIs without the ob >>> parameter, the registrar does not return Supported: outbound. >> >> [CHH] Why would every Path header need to contain the ;ob parameter? >> The >> REGISTER request may traverse, in addition to the outbound proxy,=20 >> multiple proxies which insert a Path header. Do all these proxies=20 >> really need to support outbound? >> >>> Furthermore, the registrar needs to check that the first hop after=20 >>> the >> UAC is represented in the Path list (unless the >>> registrar recognizes that the first hop after the UAC is in the same >> domain and doesn't need to include Path URIs with a >>> flow token). Note that this implies that whatever the proxy puts in >> the Via (IP address or FQDN), it must put the same >>> hostname in the Path header (but there is no need for a complete URI >> comparison). If the first hop is not correctly >>> represented, the registrar ignores the reg-id parameter and does not >> return Supported: outbound. >> >> [CHH] Isn't it much easier to mandate the outbound proxy to always=20 >> insert a Path header? >> >> OR, another possibility is that the outbound proxy, if it detects=20 >> that > >> the UAC supports outbound, insert some option-tag of itself in the=20 >> Supported header, to indicate to the registrar that it supports=20 >> outbound. Then the registrar does not need start looking at the Path=20 >> headers. >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> >> The implication of this is that an outbound-proxy that supports=20 >> outbound needs to support Path and flow tokens for registrations to=20 >> all foreign domains. Inside the same domain, the first-hop proxy and >> the registrar can still use Path to communicate with each other, but=20 >> they can use some other private mechanism to disaggregate this=20 >> functionality. >> >> thanks, >> -rohan >> >> >> _______________________________________________ >> Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 08:26:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCbUa-00083F-GX; Mon, 14 Aug 2006 08:24:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCbUY-00080j-J9 for sip@ietf.org; Mon, 14 Aug 2006 08:24:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCZP9-0002Lh-2m for sip@ietf.org; Mon, 14 Aug 2006 06:10:43 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCZ56-0002T9-RE for sip@ietf.org; Mon, 14 Aug 2006 05:50:02 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 486831944B9 for ; Mon, 14 Aug 2006 11:49:52 +0200 (CEST) Received: from [192.168.1.39] ([192.168.1.39]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 11:49:52 +0200 In-Reply-To: <11f013d932b9febb0b110906993aa989@ekabal.com> References: <5EB80D22825EEE42872083AD5BFFB594017F132C@esealmw113.eemea.ericsson.se> <02121a731098adcc1cfd384c487a3059@telio.no> <11f013d932b9febb0b110906993aa989@ekabal.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5ec559576c26e5e4cbd8741dd537d9c2@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Mon, 14 Aug 2006 11:50:26 +0200 To: Rohan Mahy X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 14 Aug 2006 09:49:52.0184 (UTC) FILETIME=[FD3DB380:01C6BF86] X-Spam-Score: -2.6 (--) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, Fredrik Thulin , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 13, 2006, at 1:23 AM, Rohan Mahy wrote: > > On Aug 11, 2006, at 6:50, Hisham Khartabil wrote: >> On Aug 11, 2006, at 3:02 PM, Christer Holmberg ((JO/LMF)) wrote: >>> Hi, >>> >>> I am sure that there are cases where messages (STUN, or whatever) >>> will >>> be sent to destinations that don't support them, e.g. due to bad >>> configuration. >>> >>> MY problem is that I don't like to standardize behavior which is >>> based >>> on sending something somewhere just to find out if the reciever >>> supports >>> the protocol in the first place. That is the reason I want to be >>> able to >>> get the information from the proxy before sending anything. >> >> Rohan's proposal is exactly what you dont want: sending something >> just to find out if the receiver supports the protocol. > > I am confused. The proposal the started this thread was to *include* > a Proxy-Require when the UAC sends its first message. If the UAC was > properly configured, this adds no additional overhead. > > The proposal that Dean and Cullen made subsequently is "try it once > and see". Again, if the UAC is properly configured, there is no extra > overhead. > > What part of these two proposals is not OK for you? I'm not OK with any proposal. As I said, I think this is an implementation issue and the draft should say nothing about it. Hisham > > thanks, > -rohan > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 08:41:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCbit-0005Vi-Cw; Mon, 14 Aug 2006 08:39:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCbir-0005VD-Om for sip@ietf.org; Mon, 14 Aug 2006 08:39:13 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCbiq-0002pZ-59 for sip@ietf.org; Mon, 14 Aug 2006 08:39:13 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k7EBd1aC022905; Mon, 14 Aug 2006 14:39:01 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 15:39:00 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 15:39:00 +0300 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 Subject: RE: [Sip] Outbound Issues: slides 3 and 4 - the problem ... Date: Mon, 14 Aug 2006 15:38:58 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F029A63D7@esebe103.NOE.Nokia.com> In-Reply-To: <7.0.1.0.0.20060810075256.02c19f38@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound Issues: slides 3 and 4 - the problem ... Thread-Index: Aca+OIE0hS2P6rKCRxqhUXqAMAW0GgBZIIvQ From: To: , , X-OriginalArrivalTime: 14 Aug 2006 12:39:00.0229 (UTC) FILETIME=[9DF27B50:01C6BF9E] X-Spam-Score: 0.2 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: sip@ietf.org, rohan@ekabal.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >I think we may have a general protocol design question whether to do=20 >some negotiation stuff or just try-and-error. I personally prefer the >latter for sake of simplicity. That means I agree totally on three and >I prefer not to do 1 or 2.=20 I have a comment not directly related to those arguments you gave but anyway an extra reason for the Outbound draft to provide a safe and deterministic check if the proxy is compliant to the draft or not. This reason is not mentioned in this thread but I would like to point it out now. Before the Montreal meeting Jonathan Rosenberg outlined an idea how an UA could automatically discover servers supporting Outbound within a domain. He described his idea in this email: http://www1.ietf.org/mail-archive/web/sip/current/msg15155.html Shortly the idea was that the home proxy of the domain would redirect the REGISTER request towards proxies supporting=20 Outbound, by sending a 305 response. Proxy would also use Service-Route and Additional-Proxies headers to indicate proxies that UA could use. In my understanding, this solution would require the UA to=20 be able to find out if the contacted Proxy supports or does not support Outbound, just in the case where the proxy did not return 305, but instead 200 OK: - Was it so that the contacted proxy supports outbound and the network does not require the UA to contact any additional proxy, so that everything is fine when receiving 200 OK that=20 does not contain Additional-Proxies header ? In this case the UA can perfectly well start sending STUN keepalives towards the proxy. - Or was it so that the proxy supports neither outbound nor this new optional draft and therefore did not return 305=20 or Additional-Proxies header ? In this case UA could make a false assumption and continue using outbound even if that would not work. Thus to make this distinction the UA has to be able to do the check, preferrably by using the Proxy-Required header as=20 described earlier in this thread. Regards, Erkki >-----Original Message----- >From: ext Jiri Kuthan [mailto:jiri@iptel.org]=20 >Sent: 10.August.2006 09:59 >To: Dean Willis; Cullen Jennings >Cc: IETF SIP List; Rohan Mahy >Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ... > >At 23:18 09/08/2006, Dean Willis wrote: >>I'm more worried about the scenario where the UA doesn't get =20 >>blacklisted, but just throws a monkeywrench in performance, and it =20 >>sucks just enough that people don't fix it but complain anyhow. > >well, I think we will be receiving useless traffic anyhow so addressing >one of endlessly many sources of useless traffic doesn't bring us much >further. With public SIP sites, we experience about 80% of=20 >"silly traffic" >(caused typically by client/server misconfigurations and/or broken >implementations). Folks who run national DNS servers shared with me >similar numbers for DNS. Implementations have to be ready to deal with >unwanted silly traffic. > > >>>For these reasons, I don't think this whole problem is not a huge =20 >>>deal. However, if people do think it is a big deal, the obvious =20 >>>solution to it is send and OPTIONS message to find out if the =20 >>>server supports this. Most people don't seem to think this is =20 >>>enough of a problem to warrant and additional RTT when a UA boots. =20 >>>We can come up with other possible solutions to this too (as there =20 >>>are at least three others on this same thread). >> >>To recap: >> >>Unacceptable: If you're configured to use STUN, just keep STUNning =20 >>whether it works or not. You may be dead, but you're right, and =20 >>that's the important part. >> >> >>Alternatives: >> >>1) Use an OPTIONS transaction before stunning to find out if the =20 >>target supports STUN >>2) Use any other SIP transaction (like REGISTER) to find out if the =20 >>target supports STUN >> a) using a Proxy-Require >> b) Using some sort of Path: tagging >>3) Just go ahead and STUN, and if it doesn't work, stop sending STUN. >> >>I'd be happy with 1+3 or 2+3. I'd even be happy with 1+3=20 >where 1 is a =20 >>"SHOULD" strength, but 3 needs to be a MUST. It may be common sense, =20 >>but it requires documentation, and people seem to need=20 >"common sense" =20 >>to have a MUST priority on it or they pretend it isn't important. >> >>If we go the 1-SHOULD+3-MUST route, we need to include the "Because =20 >>the proxy might think your STUN is an attack or error condition and =20 >>black-list you" as the explanation for the SHOULD. > >I think we may have a general protocol design question whether to do=20 >some negotiation stuff or just try-and-error. I personally prefer the >latter for sake of simplicity. That means I agree totally on three and >I prefer not to do 1 or 2. > >-jiri > > >-- >Jiri Kuthan http://iptel.org/~jiri/=20 > > >_______________________________________________ >Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 09:44:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCcia-0005IS-4R; Mon, 14 Aug 2006 09:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCciY-0005IN-MG for sip@ietf.org; Mon, 14 Aug 2006 09:42:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCciX-0005Cm-9Y for sip@ietf.org; Mon, 14 Aug 2006 09:42:58 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Aug 2006 06:42:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,121,1154934000"; d="scan'208"; a="36122771:sNHT27577648" 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.20060308/8.12.11) with ESMTP id k7EDgubK001312; Mon, 14 Aug 2006 09:42:56 -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.12.10/8.12.6) with ESMTP id k7EDguKH000951; Mon, 14 Aug 2006 09:42:56 -0400 (EDT) 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); Mon, 14 Aug 2006 09:42:56 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 09:42:55 -0400 Message-ID: <44E07DDF.50308@cisco.com> Date: Mon, 14 Aug 2006 09:42:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Outbound Issues: slides 3 and 4 References: <8B1D53AEF7B03449A6D3771B3B7F850F029A5E2A@esebe103.NOE.Nokia.com><9435CA97-BD83-4678-8A8A-46239090B6B6@cisco.com><44DE7A94.6090802@softarmor.com> <7.0.1.0.0.20060813022533.04017ec0@stevecrocker.com> <001001c6beb7$cf261570$31713b51@BEMBUSTER> In-Reply-To: <001001c6beb7$cf261570$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2006 13:42:55.0659 (UTC) FILETIME=[8C0AA7B0:01C6BFA7] DKIM-Signature: a=rsa-sha1; q=dns; l=4177; t=1155562976; x=1156426976; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Outbound=20Issues=3A=20slides=203=20and=204 |To:Jeroen=20van=20Bemmel=20; X=v=3Dcisco.com=3B=20h=3DwWC0OxKB5CM1XnDCpvhmESgafSs=3D; b=DVGUkpxILXaics40WFHj74Ep8PmxOjm21b+YemhvU4rUA0/SGh9QlBkr1Ac7Lw0B6b9PrpVV KDc9fxOQXEZAvvKHbkx3012YLCezcyS3oQlRBNnUvKC6OqKNE5tHrW6u; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: sip@ietf.org, "Joel M. Halpern" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Slightly modified proposal: > > 1) UA MUST verify that the proxy supports STUN before sending it > 2) UA MUST stop sending STUN if no response (with reasonable defined > retry interval, perhaps next boot?) > > For (1) we then have 2 defined alternatives: > 1a) using OPTIONS > 1b) using Proxy-Require > > but in addition, we should allow for alternative indications/mechanisms > that may be defined in future drafts (such as a flag in Service-Route) I gather that 1a, 1b, ... 1x *all* must be supported by the proxy? If so, what is the advantage of having more than one way? The Proxy-Require approach (1b) can be piggy backed on a message that was going to be sent anyway, eliminating extra messages. If no other message was going to be sent anyway, then it could be used with OPTIONS. I suppose sending an OPTIONS without the Proxy-Require would achieve the same result, and doesn't really require any different support in the proxy. But if that encourages some UAC implementors to use 1a when they could have used 1b, then it just puts a little bit of extra load on the proxy for no reason. An advantage of Proxy-Require is that it can be used all the time. Thus, should a change occur in network connectivity that results in a different proxy instance being contacted, it too will be checked. While the likelihood is very small of such a change occurring and resulting in a difference in support of stun, it is still an advantage to keep checking. Paul > Regards, > > Jeroen > > ----- Original Message ----- From: "Joel M. Halpern" > > To: > Sent: Sunday, August 13, 2006 8:25 AM > Subject: Re: [Sip] Outbound Issues: slides 3 and 4 > > >> I can live with that. >> Joel >> >> At 09:04 PM 8/12/2006, Dean Willis wrote: >>> Cullen Jennings wrote: >>>> On Aug 11, 2006, at 10:49 PM, >>>> wrote: >>>> >>>>> >>>>> The UA SHOULD add a Proxy-Require header field with the >>>>> value "sip-stun" to its REGISTER request. When the UA >>>>> receives 200 OK with Supported: Outbound it can be sure >>>>> that the next hop will support STUN keepalives. >>>>> >>>>> The proxy MUST remove the "sip-stun" value from the >>>>> Proxy-Require header field and then remove the header >>>>> if no values remain before forwarding the request to >>>>> the next hop. >>>> My mistake - it was some of the other stuff that was looking more >>>> complicated. I agree this is very easy implement. I also think Bob's >>>> proposal is very easy to implement - if the outbound proxy came from >>>> DHCP or was manually configured on the UA, then do an OPTIONS >>>> message first. >>> >>> >>> Yay! >>> >>> >>> How about we say: >>> >>> Either do 1 or 2 below, then always do 3: >>> >>> 1) Probe the proxy with OPTIONS to verify that it supports STUN >>> >>> or >>> >>> 2) Use a Proxy-Require as above >>> >>> and >>> >>> 3) if you don't get a STUN response, stop using STUN on this target >>> (and I'd be happy to see this in STUN, not Outbound!) >>> >>> -- >>> Dean >>> >>> _______________________________________________ >>> Sip mailing list https://www1.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://www1.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://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 11:13:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCe61-0003ql-Oa; Mon, 14 Aug 2006 11:11:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCe5z-0003qg-KD for sip@ietf.org; Mon, 14 Aug 2006 11:11:15 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCe5x-0002gA-0Y for sip@ietf.org; Mon, 14 Aug 2006 11:11:15 -0400 Received: from [131.161.248.86] (open-131-161-248-86.cliq.com [131.161.248.86]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k7EFBAF27690; Mon, 14 Aug 2006 08:11:10 -0700 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1335@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F1335@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8256efd72d64f8b36660161d9447c02d@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 08:11:38 -0700 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: SIP , Rohan Mahy , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, On Aug 13, 2006, at 23:49, Christer Holmberg ((JO/LMF)) wrote: > Hi Cullen and Rohan, > > Unfortunately I can't reply with any of the options (a,b,c or d). I do > NOT object to your proposal. In fact, I think it looks very good, but I > have a few questions: > > 1. Editorial: Shouldn't the > stop-sending-STUN-requests-if-retransmissions-fail text (point 2) be in > 3849bis? To me it sounds like generic STUN transaction procedures, > which > should be defined in the STUN spec. Or, do we consider it specific to > the STUN keepalive usage for SIP??? I don't think this is generic STUN procedures. There are reasons why you need to have different transmission policies. For example ICE would not work if we SIP STUN keepalive style restrictions on it. > 2. Functional: The proposal does not say anything about the outbound > proxy being able to indicate STUN keepalive support, i.e. by inserting > a > keepalive=stun (or something similar) in a Path/Service-Route header, > and/or the option tag in the Supported header (if the outbound proxy > happens to also be the registrar), or the REGISTER, as has been > discussed in a separate thread (I think we also agreed to keep it > within > the scope). I think it would be very useful, especially in cases where > the UA does not have any "explicit indication" beforehand, and where > the > UA does not want to send OPTIONS before sending REGISTER (e.g. due to > the fact that the UA would continue the registration no matter if the > outbound proxy supports STUN keepalive or not). Since it is unlikely that we are going to agree on this within a year, we had extremely strong support in the meeting and on the mailing list to do this work _*LATER*_. > 3. Editorial: Would it be possible to name the option tag > "sip-stun-keepalive", instead of just "sip-stun"? Or, are we sure we > will never have to be able to indicate any other type of STUN usage > support for SIP? Unless someone can provide an existence proof, I think the longer option-tag name is cumbersome and probably unnecessary. thanks, -rohan > Regards, > Christer > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 14. elokuuta 2006 1:58 > To: SIP > Cc: Rohan Mahy > Subject: [Sip] Outbound - a new STUN keealive proposal > > Hi, > > Rohan and I spent some time this afternoon trying to find a proposal > that makes more people happy than the other proposals mentioned about > STUN keepalive handling. We did this because some people expressed > concern or displeasure about one proposal or another, but keep in mind > that both of us are fine with the draft as is, in regards to this > topic. > > What we are proposing is the following: > > 1) We already agreed to move the STUN keepalive definition to a > separate > section. This makes it clear how to use STUN keepalives even for > implementations that do not use the rest of outbound. This is agreed - > we are doing it, just listing it here for completeness. > > 2) Following the basic principle of "do no harm", we propose adding > text > to tell UAs that if an initial STUN request and its retransmissions > fail, the UA MUST stop sending STUN requests to this destination. The > details of how to specify this will be difficult to articulate > succinctly, but we'd like to get agreement to this idea in principle. > The difficulty is that if a flow fails completely, this is not > necessarily indicative that the server has forgotten how to do STUN. > > 3) In the same vein, we propose adding text to make it clearer that a > UA > MUST NOT send STUN requests unless it has an explicit indication that > the target SIP server supports STUN. We can further clarify that UA > implementations should not have an ambiguous manual configuration > option > such as a "Work with NATs?" checkbox that would cause STUN keepalives > to > be used blindly. Manual configuration of an outbound URI that includes > the ";keealive=stun" parameter is considered an explicit indication. > > Now on to the new part of the proposal... > > 4) In the STUN keepalive section of the document, define a "sip-stun" > option-tag and describe its semantics (this server can receive STUN > messages and SIP messages on the same port). Describe that an OPTIONS > message MAY be used to probe or verify if a specific server supports > sip-stun. Future specifications can define other uses of this option- > tag. This leaves our options open as a WG. > > 5) In the outbound portion of the draft, make it clear that the first- > hop proxy MUST support the "sip-stun" option-tag. (If the UA probes the > first-hop, the probe needs to succeed). > > 6) Also in the outbound section of the draft, explain that that it is > NOT RECOMMENDED for a UAC to include a Proxy-Require header field with > the sip-stun option-tag. This is because the request would fail in > some > topologies where the first proxy supports sip-stun but subsequent > proxies do not. Remind implementors that RFC 3261 does not allow > proxies > to remove option-tags from a Proxy-Require header field. > > To summarize this proposal: > - It does no harm: It insures STUN is only used when explicitly > configured and provides supportive implementation guidance, and it > stops > sending STUN if the server does not respond to initial STUN traffic. > - It leaves our options open, while allowing outbound to progress: > It keeps the door open for future explicit discovery mechanisms, and > allows other potential uses of STUN keepalives. > - It works. > > Please reply to the list or to (the chairs and authors) with one of the > following choices: > a) This is fine/good/OK > b) I can live with this proposal, but prefer omitting the "sip-stun" > option-tag > c) I object (please provide reasons) > d) I don't care, just please finish the document > > Thanks, Cullen & Rohan > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 11:56:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCelh-0002Kr-Io; Mon, 14 Aug 2006 11:54:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCelf-0002Kl-Rn for sip@ietf.org; Mon, 14 Aug 2006 11:54:19 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCelf-0006DJ-2j for sip@ietf.org; Mon, 14 Aug 2006 11:54:19 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2E5E96E0001; Mon, 14 Aug 2006 17:54:18 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 17:54:17 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 17:54:17 +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 Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 17:54:16 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1347@esealmw113.eemea.ericsson.se> In-Reply-To: <8256efd72d64f8b36660161d9447c02d@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound - a new STUN keealive proposal Thread-Index: Aca/s+/KEok+VDygRoWgj4GAHrvH8wABF3fQ From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 14 Aug 2006 15:54:17.0023 (UTC) FILETIME=[E5B35CF0:01C6BFB9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: SIP , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan,=20 >>Unfortunately I can't reply with any of the options (a,b,c or d). I do >>NOT object to your proposal. In fact, I think it looks very good, but=20 >>I have a few questions: >> >>1. Editorial: Shouldn't the >>stop-sending-STUN-requests-if-retransmissions-fail text (point 2) be=20 >>in 3849bis? To me it sounds like generic STUN transaction procedures,=20 >>which should be defined in the STUN spec. Or, do we consider it=20 >>specific to the STUN keepalive usage for SIP??? >> >I don't think this is generic STUN procedures. There are reasons why you need to have different transmission policies. =20 >For example ICE would not work if we SIP STUN keepalive style restrictions on it. Ok. If everybody agree I will accept it. >>2. Functional: The proposal does not say anything about the outbound=20 >>proxy being able to indicate STUN keepalive support, i.e. by inserting >>a keepalive=3Dstun (or something similar) in a Path/Service-Route=20 >>header, and/or the option tag in the Supported header (if the outbound >>proxy happens to also be the registrar), or the REGISTER, as has been=20 >>discussed in a separate thread (I think we also agreed to keep it=20 >>within the scope). I think it would be very useful, especially in=20 >>cases where the UA does not have any "explicit indication" beforehand, >>and where the UA does not want to send OPTIONS before sending REGISTER >>(e.g. due to the fact that the UA would continue the registration no=20 >>matter if the outbound proxy supports STUN keepalive or not). > >Since it is unlikely that we are going to agree on this within a year, we had extremely strong support in the meeting and=20 >on the mailing list to do this work _*LATER*_. I haven't seen much objection to it, and both Jonathan and Cullen indicated (I appologize if I missunderstood them) that it would be useful to include it already NOW. And, we are going to define the option-tag (for OPTIONS and/or Proxy-Require) and the URI paramter (for Path and/or Service-Route) anyway, so I don't think it would add much work. And, what about the proxy inserting the "ob" parameter (see slide 9 and 10 issue)??? Isn't that needed already NOW? How is that different from the proxy inserting a STUN support indication? >>3. Editorial: Would it be possible to name the option tag=20 >>"sip-stun-keepalive", instead of just "sip-stun"? Or, are we sure we=20 >>will never have to be able to indicate any other type of STUN usage=20 >>support for SIP? > >Unless someone can provide an existence proof, I think the longer option-tag name is cumbersome and probably unnecessary. I agree that we should aim at short option-tag names, but unfortunately it's difficult to proof STUN usages which may be defined in future... :) Regards, Christer > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 14. elokuuta 2006 1:58 > To: SIP > Cc: Rohan Mahy > Subject: [Sip] Outbound - a new STUN keealive proposal > > Hi, > > Rohan and I spent some time this afternoon trying to find a proposal=20 > that makes more people happy than the other proposals mentioned about=20 > STUN keepalive handling. We did this because some people expressed=20 > concern or displeasure about one proposal or another, but keep in mind > that both of us are fine with the draft as is, in regards to this=20 > topic. > > What we are proposing is the following: > > 1) We already agreed to move the STUN keepalive definition to a=20 > separate section. This makes it clear how to use STUN keepalives even > for implementations that do not use the rest of outbound. This is=20 > agreed - we are doing it, just listing it here for completeness. > > 2) Following the basic principle of "do no harm", we propose adding=20 > text to tell UAs that if an initial STUN request and its=20 > retransmissions fail, the UA MUST stop sending STUN requests to this=20 > destination. The details of how to specify this will be difficult to=20 > articulate succinctly, but we'd like to get agreement to this idea in=20 > principle. > The difficulty is that if a flow fails completely, this is not=20 > necessarily indicative that the server has forgotten how to do STUN. > > 3) In the same vein, we propose adding text to make it clearer that a=20 > UA MUST NOT send STUN requests unless it has an explicit indication=20 > that the target SIP server supports STUN. We can further clarify that=20 > UA implementations should not have an ambiguous manual configuration=20 > option such as a "Work with NATs?" checkbox that would cause STUN=20 > keepalives to be used blindly. Manual configuration of an outbound URI > that includes the ";keealive=3Dstun" parameter is considered an = explicit > indication. > > Now on to the new part of the proposal... > > 4) In the STUN keepalive section of the document, define a "sip-stun" > option-tag and describe its semantics (this server can receive STUN=20 > messages and SIP messages on the same port). Describe that an OPTIONS=20 > message MAY be used to probe or verify if a specific server supports=20 > sip-stun. Future specifications can define other uses of this option-=20 > tag. This leaves our options open as a WG. > > 5) In the outbound portion of the draft, make it clear that the first- > hop proxy MUST support the "sip-stun" option-tag. (If the UA probes=20 > the first-hop, the probe needs to succeed). > > 6) Also in the outbound section of the draft, explain that that it is=20 > NOT RECOMMENDED for a UAC to include a Proxy-Require header field with > the sip-stun option-tag. This is because the request would fail in=20 > some topologies where the first proxy supports sip-stun but subsequent > proxies do not. Remind implementors that RFC 3261 does not allow=20 > proxies to remove option-tags from a Proxy-Require header field. > > To summarize this proposal: > - It does no harm: It insures STUN is only used when explicitly=20 > configured and provides supportive implementation guidance, and it=20 > stops sending STUN if the server does not respond to initial STUN=20 > traffic. > - It leaves our options open, while allowing outbound to progress: > It keeps the door open for future explicit discovery mechanisms, and=20 > allows other potential uses of STUN keepalives. > - It works. > > Please reply to the list or to (the chairs and authors) with one of=20 > the following choices: > a) This is fine/good/OK > b) I can live with this proposal, but prefer omitting the "sip-stun" > option-tag > c) I object (please provide reasons) > d) I don't care, just please finish the document > > Thanks, Cullen & Rohan > > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 12:00:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCepa-0003bM-RI; Mon, 14 Aug 2006 11:58:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCepa-0003bH-02 for sip@ietf.org; Mon, 14 Aug 2006 11:58:22 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCepW-0006PS-CX for sip@ietf.org; Mon, 14 Aug 2006 11:58:21 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 50BE019451D for ; Mon, 14 Aug 2006 17:58:17 +0200 (CEST) Received: from [192.168.1.39] ([192.168.1.39]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 17:58:15 +0200 In-Reply-To: <049B3664-DEE6-432C-A8B7-E7C3FB46DA28@softarmor.com> References: <5EB80D22825EEE42872083AD5BFFB594017F132C@esealmw113.eemea.ericsson.se> <02121a731098adcc1cfd384c487a3059@telio.no> <11f013d932b9febb0b110906993aa989@ekabal.com> <5ec559576c26e5e4cbd8741dd537d9c2@telio.no> <049B3664-DEE6-432C-A8B7-E7C3FB46DA28@softarmor.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Mon, 14 Aug 2006 17:58:49 +0200 To: Dean Willis X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 14 Aug 2006 15:58:15.0496 (UTC) FILETIME=[73D77480:01C6BFBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, Rohan Mahy , Fredrik Thulin , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Many, but why is this the special case? Do we want to specify ALL misconfigurations in the UA and standardise a mechanism for recovery? Hisham On Aug 14, 2006, at 4:58 PM, Dean Willis wrote: > > On Aug 14, 2006, at 4:50 AM, Hisham Khartabil wrote: > > >> >> I'm not OK with any proposal. As I said, I think this is an >> implementation issue and the draft should say nothing about it. >> > > Hold on a sec, Hisham. How many times have "implementation issues" > that related to incompletely specified behavior in some RFC turned out > to be a problem for your real-world deployments? My hunch is that this > happens fairly often, given the questions I see coming back from > network operators. > > -- > Dean > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 12:02:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCeru-0005Yu-Vu; Mon, 14 Aug 2006 12:00:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCeru-0005Yk-Gu for sip@ietf.org; Mon, 14 Aug 2006 12:00:46 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCers-0006Yc-QH for sip@ietf.org; Mon, 14 Aug 2006 12:00:46 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id ECC5119451B for ; Mon, 14 Aug 2006 18:00:43 +0200 (CEST) Received: from [192.168.1.39] ([192.168.1.39]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 18:00:44 +0200 In-Reply-To: <55148cf4d0ebe2e7ec85ae89ee28a201@ekabal.com> References: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> <3acf2324644868f606601d28443b31b3@telio.no> <55148cf4d0ebe2e7ec85ae89ee28a201@ekabal.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1c8d51d93e08e573ee3724be44ddd05a@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 18:01:17 +0200 To: Rohan Mahy X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 14 Aug 2006 16:00:44.0094 (UTC) FILETIME=[CC69B5E0:01C6BFBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Cullen Jennings , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan, Specify whatever you want, as long as its optional to implement. I will not require it from my vendors. I believe this settles it :) Thanks, Hisham On Aug 14, 2006, at 5:26 PM, Rohan Mahy wrote: > Hisham, > > We are trying to converge here. It seems pretty clear to me that > fewer people will be OK with your proposal. I'll point out that you > can ALREADY send STUN before SIP by configuring your STUN server > address to the address of your SIP server. In large part, we are > talking about the UA deciding to send STUN based on its *SIP* server > configuration. > > thanks, > -rohan > > On Aug 14, 2006, at 3:12, Hisham Khartabil wrote: >> I think we should say the following: >> >> A UA MAY do *either or both* of the following, *in any order*, in >> order to verify that an outbound proxy supports stun keepalive, IF >> the UA is configured to say that outbound proxy supports stun >> >> - send stun requests including retransmissions >> - send SIP OPTIONS request >> >> Implementers can choose the order they want. It can even be >> configurable where the service provider can configure the order. >> >> I also want to point out that the UA needs to try again after some >> units of time if stun fails, if the UA is configured to say that >> outbound proxy supports stun. The reason is that I might have >> upgraded my server to a bad version where the stun part was buggy. I >> don't want to ask my customers to reboot their UA in order to get >> stun to work again from the UA. >> >> Hisham >> >> On Aug 14, 2006, at 12:57 AM, Cullen Jennings wrote: >> >>> Hi, >>> >>> Rohan and I spent some time this afternoon trying to find a proposal >>> that makes more people happy than the other proposals mentioned >>> about STUN keepalive handling. We did this because some people >>> expressed concern or displeasure about one proposal or another, but >>> keep in mind that both of us are fine with the draft as is, in >>> regards to this topic. >>> >>> What we are proposing is the following: >>> >>> 1) We already agreed to move the STUN keepalive definition to a >>> separate section. This makes it clear how to use STUN keepalives >>> even for implementations that do not use the rest of outbound. This >>> is agreed - we are doing it, just listing it here for completeness. >>> >>> 2) Following the basic principle of "do no harm", we propose adding >>> text to tell UAs that if an initial STUN request and its >>> retransmissions fail, the UA MUST stop sending STUN requests to this >>> destination. The details of how to specify this will be difficult >>> to articulate succinctly, but we'd like to get agreement to this >>> idea in principle. The difficulty is that if a flow fails >>> completely, this is not necessarily indicative that the server has >>> forgotten how to do STUN. >>> >>> 3) In the same vein, we propose adding text to make it clearer that >>> a UA MUST NOT send STUN requests unless it has an explicit >>> indication that the target SIP server supports STUN. We can further >>> clarify that UA implementations should not have an ambiguous manual >>> configuration option such as a "Work with NATs?" checkbox that would >>> cause STUN keepalives to be used blindly. Manual configuration of an >>> outbound URI that includes the ";keealive=stun" parameter is >>> considered an explicit indication. >>> >>> Now on to the new part of the proposal... >>> >>> 4) In the STUN keepalive section of the document, define a >>> "sip-stun" option-tag and describe its semantics (this server can >>> receive STUN messages and SIP messages on the same port). Describe >>> that an OPTIONS message MAY be used to probe or verify if a specific >>> server supports sip-stun. Future specifications can define other >>> uses of this option-tag. This leaves our options open as a WG. >>> >>> 5) In the outbound portion of the draft, make it clear that the >>> first-hop proxy MUST support the "sip-stun" option-tag. (If the UA >>> probes the first-hop, the probe needs to succeed). >>> >>> 6) Also in the outbound section of the draft, explain that that it >>> is NOT RECOMMENDED for a UAC to include a Proxy-Require header field >>> with the sip-stun option-tag. This is because the request would >>> fail in some topologies where the first proxy supports sip-stun but >>> subsequent proxies do not. Remind implementors that RFC 3261 does >>> not allow proxies to remove option-tags from a Proxy-Require header >>> field. >>> >>> To summarize this proposal: >>> - It does no harm: It insures STUN is only used when explicitly >>> configured and provides supportive implementation guidance, and it >>> stops sending STUN if the server does not respond to initial STUN >>> traffic. >>> - It leaves our options open, while allowing outbound to progress: >>> It keeps the door open for future explicit discovery mechanisms, and >>> allows other potential uses of STUN keepalives. >>> - It works. >>> >>> Please reply to the list or to (the chairs and authors) with one of >>> the following choices: >>> a) This is fine/good/OK >>> b) I can live with this proposal, but prefer omitting the "sip-stun" >>> option-tag >>> c) I object (please provide reasons) >>> d) I don't care, just please finish the document >>> >>> Thanks, Cullen & Rohan >>> >>> _______________________________________________ >>> Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 12:16:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCf4u-0002PW-PO; Mon, 14 Aug 2006 12:14:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCf4s-0002PO-UH for sip@ietf.org; Mon, 14 Aug 2006 12:14:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCePL-000457-JR for sip@ietf.org; Mon, 14 Aug 2006 11:31:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCdtn-0006rW-V7 for sip@ietf.org; Mon, 14 Aug 2006 10:58:41 -0400 Received: from [192.168.2.106] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7EF0eNB012556 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 14 Aug 2006 10:00:42 -0500 In-Reply-To: <5ec559576c26e5e4cbd8741dd537d9c2@telio.no> References: <5EB80D22825EEE42872083AD5BFFB594017F132C@esealmw113.eemea.ericsson.se> <02121a731098adcc1cfd384c487a3059@telio.no> <11f013d932b9febb0b110906993aa989@ekabal.com> <5ec559576c26e5e4cbd8741dd537d9c2@telio.no> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <049B3664-DEE6-432C-A8B7-E7C3FB46DA28@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound Issues: slides 3 and 4 Date: Mon, 14 Aug 2006 09:58:19 -0500 To: Hisham Khartabil X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.2 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sip@ietf.org, Rohan Mahy , Fredrik Thulin , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 14, 2006, at 4:50 AM, Hisham Khartabil wrote: > > I'm not OK with any proposal. As I said, I think this is an > implementation issue and the draft should say nothing about it. > Hold on a sec, Hisham. How many times have "implementation issues" that related to incompletely specified behavior in some RFC turned out to be a problem for your real-world deployments? My hunch is that this happens fairly often, given the questions I see coming back from network operators. -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 12:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCfJM-0007PQ-Hw; Mon, 14 Aug 2006 12:29:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCfJL-0007PL-2K for sip@ietf.org; Mon, 14 Aug 2006 12:29:07 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCfJJ-0007xi-Ko for sip@ietf.org; Mon, 14 Aug 2006 12:29:07 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k7EGT1Zp008269; Mon, 14 Aug 2006 11:29:01 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 14 Aug 2006 11:29:01 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 14 Aug 2006 18:28:59 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Continuation of WGLC on draft-ietf-sip-gruu-10 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 14 Aug 2006 18:28:58 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180278BDD@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Continuation of WGLC on draft-ietf-sip-gruu-10 Thread-Index: Aca6aFzrGeasK0KxT4GptxUzbrWYAwFVfHDg From: "Drage, Keith \(Keith\)" To: "Cullen Jennings" X-OriginalArrivalTime: 14 Aug 2006 16:28:59.0466 (UTC) FILETIME=[BEEEF2A0:01C6BFBE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen is the only person who has picked up on this, and I have not yet seem screams of protest from the rest of the North American community. I accept that I should have checked my diary for holidays before scheduling this, and if this is an issue for significant participants I will move it. However at least doing it this way minimises scope for conflict with your ordinary work:-) Regards Keith=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 07 August 2006 22:28 > To: Drage, Keith (Keith) > Cc: IETF SIP List > Subject: Re: [Sip] Continuation of WGLC on draft-ietf-sip-gruu-10 >=20 >=20 > Just as a note - Sep 4 is a holiday many places. >=20 > On Aug 5, 2006, at 1:31 PM, Drage, Keith ((Keith)) wrote: >=20 > > Working Group Last Call > > ----------------------- > > > > Jonathan has just published > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-10.txt which=20 > > should take into account all the major comments that have=20 > been so far=20 > > received on this document. > > > > Having initiated WGLC on this document on 13th January 2004, and=20 > > revised that WGLC on 5th July 2004 and 26th October 2005 we would=20 > > really like to reach a final conclusion of this WGLC. > > > > Therefore please review the document and submit your WGLC comments=20 > > within two weeks, ie. By the 21st August 2006. > > > > Process > > ------- > > > > In addition to an open invitation for review by all members of the=20 > > working group, we will be soliciting full review by a number of=20 > > experts who we believe will provide a good and complete=20 > understanding=20 > > of the issues and problems, if any, with the document. If=20 > you consider=20 > > you should be part of this list this please contact the WG chairs. > > > > The WG chairs will compile all submitted comments into a=20 > single review=20 > > document which will be discussed on the conference call=20 > below. Please=20 > > therefore submit your comments (to the SIP WG list and the=20 > WG chairs)=20 > > with information under the following headings for each comment: > > > > - location in document > > - nature of comment (editorial, minor technical, critical error, > > absolute show stopper - use your judgement on this) > > - comment > > - proposed fix > > > > We intend to have a conference call for reviewers to=20 > conclude on the=20 > > quality of the document on Monday 4th September at: > > > > 8:00 am Pacific Time > > 10:00 am Central US Time > > 11:00 am Eastern US Time > > 4:00 pm UK > > 5:00 pm Central European Summer Time > > > > Bridge details as follows: > > > > Access Phone Number: 8007718734 > > International Access Phone Number: +1 6477233953 7-Digit=20 > Access Code: =20 > > 5776249 > > > > While this call is open to all WG members, we would expect=20 > only people=20 > > who have reviewed the document on this conference call. For=20 > details of=20 > > the process please see previous communication. Note that the above=20 > > does include those reviewers who reviewed the document and had no=20 > > comments - if you are in this class, please report it. > > > > Regards > > > > Keith > > > > Keith Drage > > drage@lucent.com > > tel: +44 1793 776249 > > > > _______________________________________________ > > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 12:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCfbt-0005o5-Jn; Mon, 14 Aug 2006 12:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCfbs-0005o0-Jg for sip@ietf.org; Mon, 14 Aug 2006 12:48:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCdDp-0007mG-EW for sip@ietf.org; Mon, 14 Aug 2006 10:15:17 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCd2m-00066j-VX for sip@ietf.org; Mon, 14 Aug 2006 10:03:55 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 14 Aug 2006 07:03:53 -0700 X-IronPort-AV: i="4.08,121,1154934000"; d="scan'208"; a="311497774:sNHT31283242" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7EE3qK0024179; Mon, 14 Aug 2006 07:03:52 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7EE3mcR000625; Mon, 14 Aug 2006 07:03:51 -0700 (PDT) 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); Mon, 14 Aug 2006 10:03:50 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 10:03:50 -0400 Message-ID: <44E082C5.5080501@cisco.com> Date: Mon, 14 Aug 2006 10:03:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "B, Nataraju" Subject: Re: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt References: <70798CF421F00F4DA018059E5B7EEB8C7A5BDA@sonusinmail01.sonusnet.com> In-Reply-To: <70798CF421F00F4DA018059E5B7EEB8C7A5BDA@sonusinmail01.sonusnet.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Aug 2006 14:03:50.0220 (UTC) FILETIME=[77D178C0:01C6BFAA] DKIM-Signature: a=rsa-sha1; q=dns; l=881; t=1155564232; x=1156428232; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20comments=20on=20draft-ietf-sipping-dialogusage-02.txt; X=v=3Dcisco.com=3B=20h=3DTH6BmAmf0rRE0cKOJxwAXgTnrbA=3D; b=UMy2YRXcf7iSk1WEtggIo8RNlsq5SFOAUltgeeRSmeTDUQ7EqckH/m8z6CJ4bdrJUb+RXhqa RhQkCAKeRadiw7Au3Q2yLm6dZcIaNZZS83sZpCyf573Os5foOkFldNb2; Authentication-Results: sj-dkim-6.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.3 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org B, Nataraju wrote: > 1. Sec 4 describes what the effects on dialog are and its usages when > particular responses are received for NOTIFY message, the responses 404, > 410, 416, lead to dialog and its usage termination. > > a. I feel we should have mentioned ONLY the authenticated NOTIFY > requests will have this effect on the dialogs/usages. Otherwise any > middle men can trace the message and send the NOTIFY messages which > terminate the dialogs, which is undesirable ☹. If the entity sending > NOTIFY really intend to do that it can resend NOTIFY with authorization > credentials which will help to terminate the associated dialogs. I agree we wouldn't want to enable a MITM attack here. But I think that is already covered. If the request isn't properly authenticated, then the response will be 401, not 404, 410, or 416. Paul _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 16:33:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCj5u-000587-4m; Mon, 14 Aug 2006 16:31:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCj5s-00056Q-Pa for sip@ietf.org; Mon, 14 Aug 2006 16:31:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCeP3-000457-7x for sip@ietf.org; Mon, 14 Aug 2006 11:30:57 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCeL3-0007HB-Ih for sip@ietf.org; Mon, 14 Aug 2006 11:26:52 -0400 Received: from [131.161.248.86] (open-131-161-248-86.cliq.com [131.161.248.86]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k7EFQXF28120; Mon, 14 Aug 2006 08:26:33 -0700 In-Reply-To: <3acf2324644868f606601d28443b31b3@telio.no> References: <9AE47FFD-4ADC-4B1A-A561-FADBD8B4ABED@cisco.com> <3acf2324644868f606601d28443b31b3@telio.no> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <55148cf4d0ebe2e7ec85ae89ee28a201@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 08:26:55 -0700 To: Hisham Khartabil X-Mailer: Apple Mail (2.624) X-Spam-Score: -2.6 (--) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Cullen Jennings , Rohan Mahy , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hisham, We are trying to converge here. It seems pretty clear to me that fewer people will be OK with your proposal. I'll point out that you can ALREADY send STUN before SIP by configuring your STUN server address to the address of your SIP server. In large part, we are talking about the UA deciding to send STUN based on its *SIP* server configuration. thanks, -rohan On Aug 14, 2006, at 3:12, Hisham Khartabil wrote: > I think we should say the following: > > A UA MAY do *either or both* of the following, *in any order*, in > order to verify that an outbound proxy supports stun keepalive, IF the > UA is configured to say that outbound proxy supports stun > > - send stun requests including retransmissions > - send SIP OPTIONS request > > Implementers can choose the order they want. It can even be > configurable where the service provider can configure the order. > > I also want to point out that the UA needs to try again after some > units of time if stun fails, if the UA is configured to say that > outbound proxy supports stun. The reason is that I might have upgraded > my server to a bad version where the stun part was buggy. I don't want > to ask my customers to reboot their UA in order to get stun to work > again from the UA. > > Hisham > > On Aug 14, 2006, at 12:57 AM, Cullen Jennings wrote: > >> Hi, >> >> Rohan and I spent some time this afternoon trying to find a proposal >> that makes more people happy than the other proposals mentioned about >> STUN keepalive handling. We did this because some people expressed >> concern or displeasure about one proposal or another, but keep in >> mind that both of us are fine with the draft as is, in regards to >> this topic. >> >> What we are proposing is the following: >> >> 1) We already agreed to move the STUN keepalive definition to a >> separate section. This makes it clear how to use STUN keepalives >> even for implementations that do not use the rest of outbound. This >> is agreed - we are doing it, just listing it here for completeness. >> >> 2) Following the basic principle of "do no harm", we propose adding >> text to tell UAs that if an initial STUN request and its >> retransmissions fail, the UA MUST stop sending STUN requests to this >> destination. The details of how to specify this will be difficult to >> articulate succinctly, but we'd like to get agreement to this idea in >> principle. The difficulty is that if a flow fails completely, this >> is not necessarily indicative that the server has forgotten how to do >> STUN. >> >> 3) In the same vein, we propose adding text to make it clearer that a >> UA MUST NOT send STUN requests unless it has an explicit indication >> that the target SIP server supports STUN. We can further clarify that >> UA implementations should not have an ambiguous manual configuration >> option such as a "Work with NATs?" checkbox that would cause STUN >> keepalives to be used blindly. Manual configuration of an outbound >> URI that includes the ";keealive=stun" parameter is considered an >> explicit indication. >> >> Now on to the new part of the proposal... >> >> 4) In the STUN keepalive section of the document, define a "sip-stun" >> option-tag and describe its semantics (this server can receive STUN >> messages and SIP messages on the same port). Describe that an OPTIONS >> message MAY be used to probe or verify if a specific server supports >> sip-stun. Future specifications can define other uses of this >> option-tag. This leaves our options open as a WG. >> >> 5) In the outbound portion of the draft, make it clear that the >> first-hop proxy MUST support the "sip-stun" option-tag. (If the UA >> probes the first-hop, the probe needs to succeed). >> >> 6) Also in the outbound section of the draft, explain that that it is >> NOT RECOMMENDED for a UAC to include a Proxy-Require header field >> with the sip-stun option-tag. This is because the request would fail >> in some topologies where the first proxy supports sip-stun but >> subsequent proxies do not. Remind implementors that RFC 3261 does not >> allow proxies to remove option-tags from a Proxy-Require header >> field. >> >> To summarize this proposal: >> - It does no harm: It insures STUN is only used when explicitly >> configured and provides supportive implementation guidance, and it >> stops sending STUN if the server does not respond to initial STUN >> traffic. >> - It leaves our options open, while allowing outbound to progress: >> It keeps the door open for future explicit discovery mechanisms, and >> allows other potential uses of STUN keepalives. >> - It works. >> >> Please reply to the list or to (the chairs and authors) with one of >> the following choices: >> a) This is fine/good/OK >> b) I can live with this proposal, but prefer omitting the "sip-stun" >> option-tag >> c) I object (please provide reasons) >> d) I don't care, just please finish the document >> >> Thanks, Cullen & Rohan >> >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 14 18:16:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCki3-0006Lg-Im; Mon, 14 Aug 2006 18:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCki1-0006Gx-Ue for sip@ietf.org; Mon, 14 Aug 2006 18:14:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCki1-0008I4-T9 for sip@ietf.org; Mon, 14 Aug 2006 18:14:57 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCkUi-0004Xp-1T for sip@ietf.org; Mon, 14 Aug 2006 18:01:14 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc12) with ESMTP id <20060814220110b1200sc9cte>; Mon, 14 Aug 2006 22:01:11 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k7EM1AeY024536 for ; Mon, 14 Aug 2006 18:01:10 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k7EM1A5a024532; Mon, 14 Aug 2006 18:01:10 -0400 Date: Mon, 14 Aug 2006 18:01:10 -0400 Message-Id: <200608142201.k7EM1A5a024532@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1550C521-0148-4C7D-8675-AAFC27A84235@cisco.com> (fluffy@cisco.com) Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound References: <1155070150.14419.18.camel@macbuster.research.nokia.com> <3135FE06-4196-44A4-9310-0AFEF22E449D@cisco.com> <200608100302.k7A32ks7013575@dragon.ariadne.com> <1550C521-0148-4C7D-8675-AAFC27A84235@cisco.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Cullen Jennings > - If you want delegated assignment, you can assign an OID, which can > be made into a URN. > Yes, I agree - but do we have a use case where someone wants to use an OID? I, personally, like OIDs (in the abstract, not for instance IDs), but that's not important. Every once in a while, someone mentions that it would be useful to allow for delegated administrative assignment of instance IDs. OIDs are a natural solution to that problem. I've not heard of anyone saying that *they* want delegated administrative assignment of instance IDs, but people mention it as a possibility. But the bigger point is that there are types of URNs for creating almost any sort of naming scheme, and by letting an instance ID be a general URN, we inherit all of that work. Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 14 21:05:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCnLS-00037R-Ii; Mon, 14 Aug 2006 21:03:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCnLR-00037M-9n for sip@ietf.org; Mon, 14 Aug 2006 21:03:49 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCnLP-0001gs-SW for sip@ietf.org; Mon, 14 Aug 2006 21:03:49 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id AD720190; Mon, 14 Aug 2006 21:03:46 -0400 From: "Hadriel Kaplan" To: "'Christer Holmberg \(JO/LMF\)'" Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 21:03:46 -0400 Message-ID: <021901c6c006$a9876f80$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1347@esealmw113.eemea.ericsson.se> Thread-Index: Aca/s+/KEok+VDygRoWgj4GAHrvH8wABF3fQABNqUtA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'SIP' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > > I agree that we should aim at short option-tag names, but unfortunately > it's difficult to proof STUN usages which may be defined in future... :) Not necessarily I think - we define "sip-stun" now. If we need to use stun for something other than keepalive in the future, it would be "sip-stun-xyz" or "sip-xyz-stun", or a second option tag only used if "sip-stun" option tag is also used, or whatever. The two strings don't match, ergo are unique and differentiating. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 15 00:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCqsx-0007lc-Ju; Tue, 15 Aug 2006 00:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCqsw-0007lX-3B for sip@ietf.org; Tue, 15 Aug 2006 00:50:38 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCqsv-0001nn-HL for sip@ietf.org; Tue, 15 Aug 2006 00:50:38 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 14 Aug 2006 21:50:37 -0700 X-IronPort-AV: i="4.08,123,1154934000"; d="scan'208"; a="1847013076:sNHT35290824" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7F4oaxk014382; Mon, 14 Aug 2006 21:50:36 -0700 Received: from [192.168.1.2] (sjc-vpn2-878.cisco.com [10.21.115.110]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7F4oacJ019138; Mon, 14 Aug 2006 21:50:36 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1335@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F1335@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 21:49:59 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=6658; t=1155617436; x=1156481436; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20-=20a=20new=20STUN=20keealive=20proposal; X=v=3Dcisco.com=3B=20h=3DzQmDCwpOdcvOPByqb5pLW7DmCkA=3D; b=PfBLkQeR+QEq8PstRtVCSknHbG6y/DrXhj/2VePt2HN88rj1zNuhimq+wwOrlHZE+tyQoKc0 OQn3AHzDxF2VwBM5+vwTdzm2LIefASC6E5b+6xlB12tJUPR3s+80Qip9; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: SIP , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 13, 2006, at 11:49 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi Cullen and Rohan, > > Unfortunately I can't reply with any of the options (a,b,c or d). I do > NOT object to your proposal. In fact, I think it looks very good, > but I > have a few questions: I think some of these questions are actually some good improvements - thanks > > 1. Editorial: Shouldn't the > stop-sending-STUN-requests-if-retransmissions-fail text (point 2) > be in > 3849bis? To me it sounds like generic STUN transaction procedures, > which > should be defined in the STUN spec. Or, do we consider it specific to > the STUN keepalive usage for SIP??? Propose some text - as much as the advice can be made generic, I would want it to be in 3849bis. I suspect it hard to say too much more than what is in 3849. > > 2. Functional: The proposal does not say anything about the outbound > proxy being able to indicate STUN keepalive support, i.e. by > inserting a > keepalive=stun (or something similar) in a Path/Service-Route header, Rohan and I meant this proposal to allow something like - if the UA found out about a URI to use in a Path/S-R header or something similar and it had the keep-alive=stun, then the UA would do stun when connecting to that URI > and/or the option tag in the Supported header (if the outbound proxy > happens to also be the registrar), or the REGISTER, as has been Again, we meant this proposal to allow something like this. We said the proxy needed to put this in the supported (if it supported it). I guess we should have said this about the Registrar too. We can update the proposal with that. > discussed in a separate thread (I think we also agreed to keep it > within > the scope). I think it would be very useful, especially in cases where > the UA does not have any "explicit indication" beforehand, and > where the > UA does not want to send OPTIONS before sending REGISTER (e.g. due to > the fact that the UA would continue the registration no matter if the > outbound proxy supports STUN keepalive or not). > > 3. Editorial: Would it be possible to name the option tag > "sip-stun-keepalive", instead of just "sip-stun"? Or, are we sure we > will never have to be able to indicate any other type of STUN usage > support for SIP? Sounds like a good suggestion - I did see you made this before - Rohan and I just did not get to this level of detail in the proposal. > > Regards, > > Christer > > > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 14. elokuuta 2006 1:58 > To: SIP > Cc: Rohan Mahy > Subject: [Sip] Outbound - a new STUN keealive proposal > > Hi, > > Rohan and I spent some time this afternoon trying to find a proposal > that makes more people happy than the other proposals mentioned about > STUN keepalive handling. We did this because some people expressed > concern or displeasure about one proposal or another, but keep in mind > that both of us are fine with the draft as is, in regards to this > topic. > > What we are proposing is the following: > > 1) We already agreed to move the STUN keepalive definition to a > separate > section. This makes it clear how to use STUN keepalives even for > implementations that do not use the rest of outbound. This is agreed - > we are doing it, just listing it here for completeness. > > 2) Following the basic principle of "do no harm", we propose adding > text > to tell UAs that if an initial STUN request and its retransmissions > fail, the UA MUST stop sending STUN requests to this destination. The > details of how to specify this will be difficult to articulate > succinctly, but we'd like to get agreement to this idea in principle. > The difficulty is that if a flow fails completely, this is not > necessarily indicative that the server has forgotten how to do STUN. > > 3) In the same vein, we propose adding text to make it clearer that > a UA > MUST NOT send STUN requests unless it has an explicit indication that > the target SIP server supports STUN. We can further clarify that UA > implementations should not have an ambiguous manual configuration > option > such as a "Work with NATs?" checkbox that would cause STUN > keepalives to > be used blindly. Manual configuration of an outbound URI that includes > the ";keealive=stun" parameter is considered an explicit indication. > > Now on to the new part of the proposal... > > 4) In the STUN keepalive section of the document, define a "sip-stun" > option-tag and describe its semantics (this server can receive STUN > messages and SIP messages on the same port). Describe that an OPTIONS > message MAY be used to probe or verify if a specific server supports > sip-stun. Future specifications can define other uses of this option- > tag. This leaves our options open as a WG. > > 5) In the outbound portion of the draft, make it clear that the first- > hop proxy MUST support the "sip-stun" option-tag. (If the UA probes > the > first-hop, the probe needs to succeed). > > 6) Also in the outbound section of the draft, explain that that it is > NOT RECOMMENDED for a UAC to include a Proxy-Require header field with > the sip-stun option-tag. This is because the request would fail in > some > topologies where the first proxy supports sip-stun but subsequent > proxies do not. Remind implementors that RFC 3261 does not allow > proxies > to remove option-tags from a Proxy-Require header field. > > To summarize this proposal: > - It does no harm: It insures STUN is only used when explicitly > configured and provides supportive implementation guidance, and it > stops > sending STUN if the server does not respond to initial STUN traffic. > - It leaves our options open, while allowing outbound to progress: > It keeps the door open for future explicit discovery mechanisms, and > allows other potential uses of STUN keepalives. > - It works. > > Please reply to the list or to (the chairs and authors) with one of > the > following choices: > a) This is fine/good/OK > b) I can live with this proposal, but prefer omitting the "sip-stun" > option-tag > c) I object (please provide reasons) > d) I don't care, just please finish the document > > Thanks, Cullen & Rohan > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 15 00:57:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCqyF-0001Fk-Ux; Tue, 15 Aug 2006 00:56:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCqyE-0001Ff-K3 for sip@ietf.org; Tue, 15 Aug 2006 00:56:06 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCqyD-00027h-BV for sip@ietf.org; Tue, 15 Aug 2006 00:56:06 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 14 Aug 2006 21:56:05 -0700 X-IronPort-AV: i="4.08,123,1154934000"; d="scan'208"; a="1847014377:sNHT31783716" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7F4u4Rl015742; Mon, 14 Aug 2006 21:56:04 -0700 Received: from [192.168.1.2] (sjc-vpn2-878.cisco.com [10.21.115.110]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7F4u4cJ020575; Mon, 14 Aug 2006 21:56:04 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F133A@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F133A@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6963724A-0F8F-4350-ACCB-83060863CC87@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound - a new STUN keealive proposal Date: Mon, 14 Aug 2006 21:55:57 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=839; t=1155617764; x=1156481764; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=20-=20a=20new=20STUN=20keealive=20proposal; X=v=3Dcisco.com=3B=20h=3DzQmDCwpOdcvOPByqb5pLW7DmCkA=3D; b=DqedMtFhJ78Q/gc/pJxJjmk6yOHeJmTrbD98bVYgyxZztrdC/W8vqbI5hoR4Xfwsw24MvAmz eFfUKOEtuUfmEi+Pluazu4JHZtAL7XICdKdE3XsIUaBFAgyTd41XcWd+; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: SIP , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 14, 2006, at 12:51 AM, Christer Holmberg ((JO/LMF)) wrote: > In another thread I proposed to, instead of using keepalive=stun, we > would use the same value as we use for the option-tag (e.g. > sip-stun-keepalive). My individual feeling on this is I would be fine with this - I'm not sure if others would or not. The selection of which keep alive mechanism to use was very controversial and people seemed to feel like keep-alive=foo might make it easier to have different keep alive mechanisms. I'm not sure I follow this logic as one could always have a foo-keepalive uri parameter if a new keep alive method was defined and the alternative seemed harder given many SIP stacks handling of multiple parameters with the same name. Anyways, I'm happy either way. I'm not sure everyone would be OK with this or not. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 15 09:02:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyXZ-0004V1-It; Tue, 15 Aug 2006 09:01:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyXY-0004UF-15 for Sip@ietf.org; Tue, 15 Aug 2006 09:01:04 -0400 Received: from web8701.mail.in.yahoo.com ([203.84.221.122]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GCyO2-0008Na-Ro for Sip@ietf.org; Tue, 15 Aug 2006 08:51:17 -0400 Received: (qmail 94093 invoked by uid 60001); 15 Aug 2006 12:44:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PA9iKiiE+PMRgzgYdt0m/vOdlIUINX8R2j+HCSF9dbRd04nYfuTs1NGRMIR1oSrqYpJcJBrFw9jy+T/o9xzP4lrtDd8AgkoS4+4+Me04vqo0CZ3pZISFJYYcCtjgLlyNPwwGOGIFaepZCuIVot4v03lQyFZ7zsPLPLaES9NC0fY= ; Message-ID: <20060815124433.94091.qmail@web8701.mail.in.yahoo.com> Received: from [220.224.36.49] by web8701.mail.in.yahoo.com via HTTP; Tue, 15 Aug 2006 13:44:33 BST Date: Tue, 15 Aug 2006 13:44:33 +0100 (BST) From: AMIT KUNDRA To: Sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Sip] Interworking between Wireline Softswitch & a CDMA softswitch !!!!! X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1966869454==" Errors-To: sip-bounces@ietf.org --===============1966869454== Content-Type: multipart/alternative; boundary="0-1855722806-1155645873=:93511" Content-Transfer-Encoding: 8bit --0-1855722806-1155645873=:93511 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi , I have one doubt. For one of our clients , having CDMA Mobile services & Wireline services If we are to have interworking between a Wireline Softswitch & a CDMA Softswitch then do we use SIP or BICC ? as many people think that BICC is more clearly defines than SIP . From this I have 3 more queries: 1. Is SIP & BICC the same kind of protocol with just the difference that BICC is part of SS7 suite & while SIP is part of VoIP suite ? 2. If different then what is this talk about integarting BICC into SIP ? 3. Is there any SIP variant, called SIP-I as I only know the SIP & SIP-T ? 4. Pls clearly distinguish between SIP,SIP-T & SIP-I with practical examples as to where which to be used ? Pls respond urgently --------------------------------- Here's a new way to find what you're looking for - Yahoo! Answers Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW --0-1855722806-1155645873=:93511 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi ,
 
I have one doubt. For one of our clients , having CDMA Mobile services & Wireline services If we are to have interworking between a Wireline Softswitch & a CDMA Softswitch then do we use SIP or BICC ? as many people think that BICC is more clearly defines than SIP . From this I have 3 more queries:
 
1. Is SIP & BICC the same kind of protocol with just the difference that BICC is part of SS7  suite & while SIP is part of VoIP suite ?
 
2. If different then what is this talk about integarting BICC into SIP ?
 
3. Is there any SIP variant, called SIP-I as I only know the SIP & SIP-T ?
 
4. Pls clearly distinguish between SIP,SIP-T & SIP-I with practical examples as to where which to be used ?
 
Pls respond urgently
 

Here's a new way to find what you're looking for - Yahoo! Answers
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW --0-1855722806-1155645873=:93511-- --===============1966869454== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============1966869454==-- From sip-bounces@ietf.org Tue Aug 15 13:37:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2nZ-0001bD-25; Tue, 15 Aug 2006 13:33:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2nX-0001b7-Ik for Sip@ietf.org; Tue, 15 Aug 2006 13:33:51 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2nV-0001ir-9J for Sip@ietf.org; Tue, 15 Aug 2006 13:33:51 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k7FHXlDo002021; Tue, 15 Aug 2006 13:33:47 -0400 (EDT) In-Reply-To: <20060815124433.94091.qmail@web8701.mail.in.yahoo.com> Subject: Re: [Sip] Interworking between Wireline Softswitch & a CDMA softswitch !!!!! To: AMIT KUNDRA X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Tue, 15 Aug 2006 13:33:45 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 08/15/2006 01:32:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.4 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 3GPP (and 3GPP2 for CDMA) defines IMS (IP Multimedia Subsystem) which covers both wireless and wireline softswitches. At one point IMS specified BICC for voice calls and SIP for other multimedia calls, but the more recent releases of IMS specify SIP for voice calls as well. I work with a number of wireless and wireline switch vendors (including softswitch vendors), and all of them are using SIP to communicate with other vendor's equipment. (some use proprietary protocols to communicate with their own equipment). Nobody has mentioned BICC in several years. SIP is a protocol. SIP-T is a BCP describing a consistent way to USE SIP for telephony applications. I am not familiar with SIP-I. SIP-T focuses on getting the SS7 signalling THROUGH an "island" of IP, so that the SS7 signalling emerges intact at the other end. If you want to have a impact on what happens WITHIN the IP network, you typically need to use more of the SIP functionality that just that covered in SIP-T. Janet -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 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. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- AMIT KUNDRA To Sip@ietf.org 08/15/2006 08:44 cc AM Subject [Sip] Interworking between Wireline Softswitch & a CDMA softswitch !!!!! Hi , I have one doubt. For one of our clients , having CDMA Mobile services & Wireline services If we are to have interworking between a Wireline Softswitch & a CDMA Softswitch then do we use SIP or BICC ? as many people think that BICC is more clearly defines than SIP . From this I have 3 more queries: 1. Is SIP & BICC the same kind of protocol with just the difference that BICC is part of SS7 suite & while SIP is part of VoIP suite ? 2. If different then what is this talk about integarting BICC into SIP ? 3. Is there any SIP variant, called SIP-I as I only know the SIP & SIP-T ? 4. Pls clearly distinguish between SIP,SIP-T & SIP-I with practical examples as to where which to be used ? Pls respond urgently Here's a new way to find what you're looking for - Yahoo! Answers Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW_______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 15 14:32:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3en-0002Xr-3n; Tue, 15 Aug 2006 14:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3el-0002T5-5b for Sip@ietf.org; Tue, 15 Aug 2006 14:28:51 -0400 Received: from [12.38.203.91] (helo=EMPBEDEX.empirix.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD3Su-0004Nk-2T for Sip@ietf.org; Tue, 15 Aug 2006 14:16:40 -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 Subject: RE: [Sip] Interworking between Wireline Softswitch & a CDMAsoftswitch !!!!! Date: Tue, 15 Aug 2006 14:16:34 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Interworking between Wireline Softswitch & a CDMAsoftswitch !!!!! Thread-Index: AcbAkX91im1n8xlqRIyMpNgMEd72uwABI1Og From: "Beith, Gordon" To: "Janet P Gunn" , "AMIT KUNDRA" X-Spam-Score: 0.4 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org SIP-T is IETF's version called SIP for Telephones (kind of an odd name, since it is for SS7 ISUP, not POTS) SIP-I is essentially ITU-T's version called SIP for BICC or ISUP So, for SS7 ISUP intents and purposes, SIP-T is virtually the same as SIP-I, except that SIP-I also caters for BICC. Regards, Gordon -----Original Message----- From: Janet P Gunn [mailto:jgunn6@csc.com]=20 Sent: Tuesday, August 15, 2006 1:34 PM To: AMIT KUNDRA Cc: Sip@ietf.org Subject: Re: [Sip] Interworking between Wireline Softswitch & a CDMAsoftswitch !!!!! 3GPP (and 3GPP2 for CDMA) defines IMS (IP Multimedia Subsystem) which covers both wireless and wireline softswitches. At one point IMS specified BICC for voice calls and SIP for other multimedia calls, but the more recent releases of IMS specify SIP for voice calls as well. I work with a number of wireless and wireline switch vendors (including softswitch vendors), and all of them are using SIP to communicate with other vendor's equipment. (some use proprietary protocols to communicate with their own equipment). Nobody has mentioned BICC in several years. SIP is a protocol. SIP-T is a BCP describing a consistent way to USE SIP for telephony applications. I am not familiar with SIP-I. SIP-T focuses on getting the SS7 signalling THROUGH an "island" of IP, so that the SS7 signalling emerges intact at the other end. If you want to have a impact on what happens WITHIN the IP network, you typically need to use more of the SIP functionality that just that covered in SIP-T. Janet ------------------------------------------------------------------------ ------------------------------------------------------------------------ -------------------------------- 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. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -------------------------------- =20 AMIT KUNDRA To=20 Sip@ietf.org 08/15/2006 08:44 cc=20 AM =20 Subject=20 [Sip] Interworking between Wireline=20 Softswitch & a CDMA softswitch !!!!! =20 =20 =20 =20 =20 =20 Hi , I have one doubt. For one of our clients , having CDMA Mobile services & Wireline services If we are to have interworking between a Wireline Softswitch & a CDMA Softswitch then do we use SIP or BICC ? as many people think that BICC is more clearly defines than SIP . From this I have 3 more queries: 1. Is SIP & BICC the same kind of protocol with just the difference that BICC is part of SS7 suite & while SIP is part of VoIP suite ? 2. If different then what is this talk about integarting BICC into SIP ? 3. Is there any SIP variant, called SIP-I as I only know the SIP & SIP-T ? 4. Pls clearly distinguish between SIP,SIP-T & SIP-I with practical examples as to where which to be used ? Pls respond urgently Here's a new way to find what you're looking for - Yahoo! Answers Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW_______________________________________________ Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 15 17:30:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD6RG-0007Ik-BH; Tue, 15 Aug 2006 17:27:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD6RF-0007If-FK for sip@ietf.org; Tue, 15 Aug 2006 17:27:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD6R4-0002th-IB for sip@ietf.org; Tue, 15 Aug 2006 17:27:05 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3FF986E0001; Tue, 15 Aug 2006 23:26:49 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 23:26:48 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 23:26:48 +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 Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Tue, 15 Aug 2006 23:26:47 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F134B@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound - a new STUN keealive proposal Thread-Index: AcbAJlsJCNXDRm04SXe16hJYaQZ6XwAhyqoQ From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" X-OriginalArrivalTime: 15 Aug 2006 21:26:48.0388 (UTC) FILETIME=[840DD040:01C6C0B1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: SIP , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >> Unfortunately I can't reply with any of the options (a,b,c or d). I do=20 >> NOT object to your proposal. In fact, I think it looks very good, but >> I have a few questions: > >I think some of these questions are actually some good improvements - thanks > >> 1. Editorial: Shouldn't the stop-sending-STUN-requests-if-retransmissions-fail text (point 2) =20 >> be in 3849bis? To me it sounds like generic STUN transaction procedures, =20 >> which should be defined in the STUN spec. Or, do we consider it specific to >> the STUN keepalive usage for SIP??? > >Propose some text - as much as the advice can be made generic, I would want it to be in 3849bis. I suspect it hard to say=20 >too much more than what is in 3849. I need to think a little more about this a little bit more. Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, and when a transaction shall be considered to have failed. But, there is no text about what happens after that. THAT may be STUN usage dependent, though, and in some cases it could even be "an implementation issue"... But, I don't see anything SIP specific in saying that STUN keep-alive re-transmissions shall stop if there is no reply, so shouldn't that text be in 3849bis - either in the generic transaction chapter (chapter 7), or in the keep-alive usage chapter (12.4)? The part of the outbound spec defining the SIP usage of STUN keep-alive can then of course refer to that text in 3849bis. My main concern is that we dont specify things which people will later find out belongs to another spec, and another WG. >>2. Functional: The proposal does not say anything about the outbound >>proxy being able to indicate STUN keepalive support, i.e. by =20 >>inserting a keepalive=3Dstun (or something similar) in a Path/Service-Route header, > >Rohan and I meant this proposal to allow something like - if the UA =20 >found out about a URI to use in a Path/S-R header or something =20 >similar and it had the keep-alive=3Dstun, then the UA would do stun =20 >when connecting to that URI Ok. Point 3 did not make that very clear, though, because it only talked about a configured URI indicating keep-alive=3Dstun.=20 But, if the URI can also come from the proxy itself (in the Path/S-R/whatever header) in the registration response I am ok with the proposal. Could you perhaps clarify that in Cthe proposal? >>and/or the option tag in the Supported header (if the outbound proxy >>happens to also be the registrar), or the REGISTER, as has been > >Again, we meant this proposal to allow something like this. We said =20 >the proxy needed to put this in the supported (if it supported it). >I guess we should have said this about the Registrar too. We can update >the proposal with that. I guess you can say that the indication is put in the Supported header if the outbound proxy and the registrar happen to be the same entity. Otherwise the proxy would insert the indication in Path, S-R or whatever we decided upon. I think the outbound proxy should insert the STUN keep-alive indication in the SAME header where it inserts the outbound ("ob") indication. Currently that is the Path header (see slide 9 and 10 proposal), but I know Jonathan had some ideas of using S-R. Regards, Christer > discussed in a separate thread (I think we also agreed to keep it =20 > within > the scope). I think it would be very useful, especially in cases where > the UA does not have any "explicit indication" beforehand, and =20 > where the > UA does not want to send OPTIONS before sending REGISTER (e.g. due to > the fact that the UA would continue the registration no matter if the > outbound proxy supports STUN keepalive or not). > > 3. Editorial: Would it be possible to name the option tag > "sip-stun-keepalive", instead of just "sip-stun"? Or, are we sure we > will never have to be able to indicate any other type of STUN usage > support for SIP? Sounds like a good suggestion - I did see you made this before - =20 Rohan and I just did not get to this level of detail in the proposal. > > Regards, > > Christer > > > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 14. elokuuta 2006 1:58 > To: SIP > Cc: Rohan Mahy > Subject: [Sip] Outbound - a new STUN keealive proposal > > Hi, > > Rohan and I spent some time this afternoon trying to find a proposal > that makes more people happy than the other proposals mentioned about > STUN keepalive handling. We did this because some people expressed > concern or displeasure about one proposal or another, but keep in mind > that both of us are fine with the draft as is, in regards to this =20 > topic. > > What we are proposing is the following: > > 1) We already agreed to move the STUN keepalive definition to a =20 > separate > section. This makes it clear how to use STUN keepalives even for > implementations that do not use the rest of outbound. This is agreed - > we are doing it, just listing it here for completeness. > > 2) Following the basic principle of "do no harm", we propose adding =20 > text > to tell UAs that if an initial STUN request and its retransmissions > fail, the UA MUST stop sending STUN requests to this destination. The > details of how to specify this will be difficult to articulate > succinctly, but we'd like to get agreement to this idea in principle. > The difficulty is that if a flow fails completely, this is not > necessarily indicative that the server has forgotten how to do STUN. > > 3) In the same vein, we propose adding text to make it clearer that =20 > a UA > MUST NOT send STUN requests unless it has an explicit indication that > the target SIP server supports STUN. We can further clarify that UA > implementations should not have an ambiguous manual configuration =20 > option > such as a "Work with NATs?" checkbox that would cause STUN =20 > keepalives to > be used blindly. Manual configuration of an outbound URI that includes > the ";keealive=3Dstun" parameter is considered an explicit indication. > > Now on to the new part of the proposal... > > 4) In the STUN keepalive section of the document, define a "sip-stun" > option-tag and describe its semantics (this server can receive STUN > messages and SIP messages on the same port). Describe that an OPTIONS > message MAY be used to probe or verify if a specific server supports > sip-stun. Future specifications can define other uses of this option- > tag. This leaves our options open as a WG. > > 5) In the outbound portion of the draft, make it clear that the first- > hop proxy MUST support the "sip-stun" option-tag. (If the UA probes =20 > the > first-hop, the probe needs to succeed). > > 6) Also in the outbound section of the draft, explain that that it is > NOT RECOMMENDED for a UAC to include a Proxy-Require header field with > the sip-stun option-tag. This is because the request would fail in =20 > some > topologies where the first proxy supports sip-stun but subsequent > proxies do not. Remind implementors that RFC 3261 does not allow =20 > proxies > to remove option-tags from a Proxy-Require header field. > > To summarize this proposal: > - It does no harm: It insures STUN is only used when explicitly > configured and provides supportive implementation guidance, and it =20 > stops > sending STUN if the server does not respond to initial STUN traffic. > - It leaves our options open, while allowing outbound to progress: > It keeps the door open for future explicit discovery mechanisms, and > allows other potential uses of STUN keepalives. > - It works. > > Please reply to the list or to (the chairs and authors) with one of =20 > the > following choices: > a) This is fine/good/OK > b) I can live with this proposal, but prefer omitting the "sip-stun" > option-tag > c) I object (please provide reasons) > d) I don't care, just please finish the document > > Thanks, Cullen & Rohan > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 15 17:51:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD6mc-0006jm-14; Tue, 15 Aug 2006 17:49:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD6mb-0006ip-02; Tue, 15 Aug 2006 17:49:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD3oL-00064s-Bu; Tue, 15 Aug 2006 14:38:45 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GD3iR-0005md-Nf; Tue, 15 Aug 2006 14:32:43 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.6/IER-o) with ESMTP id k7FIWWvr018471; Tue, 15 Aug 2006 13:32:38 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Aug 2006 13:32:32 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Aug 2006 20:32:29 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have anHTTPdereferencemechanism defined Date: Tue, 15 Aug 2006 20:32:29 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180278FD6@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [Geopriv] Does Location-Conveyance have anHTTPdereferencemechanism defined Thread-Index: Aca1B+ZeLLsjYFmHQQ2U8yRlbuTwXgAIJqCAAtvtv1A= From: "Drage, Keith \(Keith\)" To: "Dawson, Martin" , "Andrew Newton" , "Winterbottom, James" X-OriginalArrivalTime: 15 Aug 2006 18:32:29.0936 (UTC) FILETIME=[2A54AF00:01C6C099] X-Spam-Score: -1.9 (-) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: IETF SIP List , "Rosen, Brian" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I must admit I am still having trouble working out what your position, and that of Henning and James W. is. 1) The dereferencing protocol is a using protocol according to the GEOPRIV RFCs. I assume that GEOPRIV is therefore going to require that such a using protocol meets their requirements. HTTP in its current form does not meet those requirements. Is there anything here you disagree with? 2) So then we get to the step of should the URI conveyance police the using protocol that can be used, which is essentially what Brian is proposing. I certainly understand that it should be policed somewhere, and if it is not policed by the syntax of the protocol, it either has to be policed by the dereferencer, or by the location provider itself. Where do you stand on this? To me it seems automatic to police it by the types of URI that are allowed to be used, and therefore I need to understand how you see this. 3) If you agree that we police by the types of URI to be used, is the problem here then that GEOPRIV rather than SIP should write the document that makes these constraints? Regards Keith > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > Sent: 01 August 2006 06:14 > To: Andrew Newton; Winterbottom, James > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance=20 > have anHTTPdereferencemechanism defined >=20 > I'm OK as long as the ABNF includes the AbsoluteURI option=20 > and the text does not say anything specifically about=20 > excluding HTTP (or any other form of URI). >=20 > I've attempted to point out previously that the URI doesn't=20 > actually convey anything about whether the geopriv rules are=20 > going to be respected or not. It's actually a geopriv rule=20 > that those rules be respected so it's superfluous, and out of=20 > scope, to also require the statement in a SIP conveyance document. >=20 > AbsoluteURI as a generic form, encompasses sip etc. anyway,=20 > so it's also superfluous to include those in the ABNF.=20 > However, it's also a harmless waste of space. If Brian is=20 > keen to include them for some reason, and as long as neither=20 > the text nor the ABNF bias the specification toward those=20 > forms in any way, then there are certainly better things to=20 > lose sleep over. >=20 > Cheers, > Martin >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Tuesday, 1 August 2006 11:15 AM > > To: Winterbottom, James > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an=20 > > HTTPdereferencemechanism defined > >=20 > >=20 > > On Jul 31, 2006, at 9:11 PM, Winterbottom, James wrote: > >=20 > > > Hi Andy, > > > > > > That is all I have asked for, do not constrain the ABNF.=20 > If "how I=20 > > > use HTTP as a reference" goes in a different document=20 > that is fine=20 > > > providing the ABNF is not constrained in the conveyance=20 > > > specification. This is not how I read Brian's statement below: > > > > > > "This is NOT the discussion of what the ABNF of the=20 > location header=20 > > > looks like (although it would NOT have http/https in it=20 > for sure if=20 > > > we > agree > > > that an HTTP dereference protocol is a separate draft)." > > > > > > Which to me clearly says the ABNF will be restrict to=20 > exclude HTTP/=20 > > > HTTPS if there is agreement that the conveyance draft=20 > doesn't have=20 > > > specific text on how to deference an HTTP reference. > > > > > > Cheers > > > James > >=20 > > Please keep in mind that this does not stop the draft from=20 > using MUST/=20 > > SHOULD language from stipulating "the URI MUST be a GEOPRIV=20 > standards=20 > > track using protocol." > >=20 > > -andy > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 15 17:55:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD6rA-0007ta-AV; Tue, 15 Aug 2006 17:53:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD6r9-0007tG-At for sip@ietf.org; Tue, 15 Aug 2006 17:53:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD6r4-0004vQ-R8 for sip@ietf.org; Tue, 15 Aug 2006 17:53:51 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Aug 2006 14:53:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,128,1154934000"; d="scan'208"; a="36384621:sNHT23503660" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7FLrk7m027974; Tue, 15 Aug 2006 17:53:46 -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.12.10/8.12.6) with ESMTP id k7FLrjh5002077; Tue, 15 Aug 2006 17:53:46 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 17:53:46 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 17:53:45 -0400 Message-ID: <44E24269.7060604@cisco.com> Date: Tue, 15 Aug 2006 17:53:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 References: <20060814021814.B719A222425@laser.networkresonance.com> In-Reply-To: <20060814021814.B719A222425@laser.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Aug 2006 21:53:45.0323 (UTC) FILETIME=[47D283B0:01C6C0B5] DKIM-Signature: a=rsa-sha1; q=dns; l=2091; t=1155678826; x=1156542826; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-ietf-sip-gruu-10 |To:Eric=20Rescorla=20; X=v=3Dcisco.com=3B=20h=3DIhYcytQwHYv3ZD0NF3ad3b/43PQ=3D; b=J8wcW8wyQHi4Kn/577oet4NgLRQoRGadyTB+EOjhz8xo6CPzSqtoOEmZw3xQHmfTNpPsr1EK SgiRGsWyhMWhWgezaqigbNE+oFa8WwHFmQTggscGo0nMBRK032/wFRsU; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric raised a lot of issues. I've been waiting to see Jonathan's response. Meanwhile I'll try to add my opinion about a couple of them. Paul Eric Rescorla wrote: > Why is it necessary to have GRUUs which are (1) identifiable > as GRUUs to peers but (2) can't be translated back to the AOR > by the peer? A use case might help here: - Bob has an "unlisted" AOR. - Alice calls Bob. (She knows the AOR.) - Alice does a transfer, transferring Charlie to Bob, replacing Alice:Bob call To do this, Alice sends a REFER to Charlie, with a Refer-To containing the contact URI from her dialog with Bob. Bob doesn't want Charlie to be able to learn his AOR as a result of this. If Bob uses a gruu obtained from the registrar for his AOR, he doesn't want Charlie to be able to reconstruct the AOR from it. Note that the peer (Alice) that first receives this gruu knows what AOR it is associated with, because she called it. This correlation is not available when the request gets to another peer - Charlie. > However, forwarding services, such as call forwarding, SHOULD NOT be > provided for requests sent to a GRUU. The intent of the GRUU is to > target a specific UA instance, and this is incompatible with > forwarding operations. > > This seems to me to get into policy. Are you saying that I can't > have my cell phone forward calls to some other phone just cause > people call my cell number rather than my generic "EKR" AOR? One intent of a gruu is to identify a specific UA instance. A service that ignores that intent will in general be counter productive. But this is a gray area, and so it is hard to state a precise yet general rule that can be used to decide whether a particular service should be applied to a request targeting a gruu. I think all the draft can do is sensitize developers to the issue, so that they think carefully about it regarding each service. The target UA itself can also decide to forward if it wants. But again it ought to take the intent into account. Thanks, Paul _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 15 18:04:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD6zb-0001PY-6y; Tue, 15 Aug 2006 18:02:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD6zZ-0001PP-AP for sip@ietf.org; Tue, 15 Aug 2006 18:02:33 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD6zX-0005aE-VC for sip@ietf.org; Tue, 15 Aug 2006 18:02:33 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7FM2Rs25524; Tue, 15 Aug 2006 18:02:28 -0400 (EDT) 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 Subject: RE: [Sip] Comments on draft-ietf-sip-gruu-10 Date: Tue, 15 Aug 2006 17:02:13 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710FED3732@zrc2hxm2.corp.nortel.com> In-Reply-To: <44E24269.7060604@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-ietf-sip-gruu-10 Thread-Index: AcbAtWqMKDg8l60CS9ikiSiM6ylouQAAGlvg From: "Brian Stucker" To: "Paul Kyzivat" , "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hmm.. I beg to differ from the "local policy" argument about forwarding services and GRUUs. If a GRUU is generally subject to the same type of routing as a non-GRUU URI, then what's the point of having a GRUU? So you can guess as to what the heck the proxy is going to do with it? Maybe it'll act like a GRUU.... Maybe it won't...=20 We already have a mechanism for SIP URIs that don't act like a GRUU, they're called AORs. If someone wants their requests to route like an AOR, then they should return an AOR, and not a GRUU. Regards, Brian=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, August 15, 2006 4:54 PM > To: Eric Rescorla > Cc: sip@ietf.org > Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 >=20 > Eric raised a lot of issues. I've been waiting to see=20 > Jonathan's response. Meanwhile I'll try to add my opinion=20 > about a couple of them. >=20 > Paul >=20 > Eric Rescorla wrote: >=20 > > Why is it necessary to have GRUUs which are (1)=20 > identifiable as GRUUs=20 > > to peers but (2) can't be translated back to the AOR by the peer? >=20 > A use case might help here: >=20 > - Bob has an "unlisted" AOR. > - Alice calls Bob. (She knows the AOR.) > - Alice does a transfer, > transferring Charlie to Bob, replacing Alice:Bob call >=20 > To do this, Alice sends a REFER to Charlie, with a Refer-To=20 > containing the contact URI from her dialog with Bob. >=20 > Bob doesn't want Charlie to be able to learn his AOR as a=20 > result of this. If Bob uses a gruu obtained from the=20 > registrar for his AOR, he doesn't want Charlie to be able to=20 > reconstruct the AOR from it. >=20 > Note that the peer (Alice) that first receives this gruu=20 > knows what AOR it is associated with, because she called it.=20 > This correlation is not available when the request gets to=20 > another peer - Charlie. >=20 > > However, forwarding services, such as call forwarding,=20 > SHOULD NOT be > > provided for requests sent to a GRUU. The intent of the=20 > GRUU is to > > target a specific UA instance, and this is incompatible with > > forwarding operations. > >=20 > > This seems to me to get into policy. Are you saying that I=20 > can't have=20 > > my cell phone forward calls to some other phone just cause=20 > people call=20 > > my cell number rather than my generic "EKR" AOR? >=20 > One intent of a gruu is to identify a specific UA instance. A=20 > service that ignores that intent will in general be counter=20 > productive. >=20 > But this is a gray area, and so it is hard to state a precise=20 > yet general rule that can be used to decide whether a=20 > particular service should be applied to a request targeting a=20 > gruu. I think all the draft can do is sensitize developers to=20 > the issue, so that they think carefully about it regarding=20 > each service. >=20 > The target UA itself can also decide to forward if it wants.=20 > But again it ought to take the intent into account. >=20 > Thanks, > Paul >=20 > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 15 20:20:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD95G-0003uH-Ej; Tue, 15 Aug 2006 20:16:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD95E-0003sS-O4 for sip@ietf.org; Tue, 15 Aug 2006 20:16:32 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD95C-0002Tw-EH for sip@ietf.org; Tue, 15 Aug 2006 20:16:32 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 15 Aug 2006 17:16:30 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7G0GTEP013481; Tue, 15 Aug 2006 17:16:29 -0700 Received: from dwingwxp (sjc-vpn4-518.cisco.com [10.21.82.6]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7G0GSSl027277; Tue, 15 Aug 2006 17:16:28 -0700 (PDT) From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , "'Cullen Jennings'" Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Tue, 15 Aug 2006 17:16:20 -0700 Message-ID: <063501c6c0c9$36fdf3d0$0652150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbAJlsJCNXDRm04SXe16hJYaQZ6XwAhyqoQAAatv8A= In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F134B@esealmw113.eemea.ericsson.se> DKIM-Signature: a=rsa-sha1; q=dns; l=2085; t=1155687390; x=1156551390; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[Sip]=20Outbound=20-=20a=20new=20STUN=20keealive=20proposal; X=v=3Dcisco.com=3B=20h=3DAikrTB3w+Q+lGAQyxSJvTzUBl8E=3D; b=O3QkHigrgGZrYojDBAnl60KXuXeqm0Ec5+0FsHGyPKORkwRsfGw9SM7jSx/EyumT765nc+3J nDBkhLJC9Jov5WmpJ9Z66lSlh85jgnlwVxaI2o75bms+3DWoDuRFvgwz; Authentication-Results: sj-dkim-8.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'SIP' , 'Rohan Mahy' , ietf-behave@list.sipfoundry.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >> 1. Editorial: Shouldn't the > >> stop-sending-STUN-requests-if-retransmissions-fail text (point > >> 2) be in 3849bis? To me it sounds like generic STUN > >> transaction procedures, which should be defined in the STUN > >> spec. Or, do we consider it specific to the STUN keepalive > >> usage for SIP??? > > > >Propose some text - as much as the advice can be made generic, I > >would want it to be in 3849bis. I suspect it hard to say too much > >more than what is in 3849. > > I need to think a little more about this a little bit more. > > Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, > and when a transaction shall be considered to have failed. But, > there is no text about what happens after that. THAT may be STUN > usage dependent, though, and in some cases it could even be "an > implementation issue"... > > But, I don't see anything SIP specific in saying that STUN > keep-alive re-transmissions shall stop if there is no reply, so > shouldn't that text be in 3849bis - either in the generic > transaction chapter (chapter 7), or in the keep-alive usage chapter > (12.4)? The part of the outbound spec defining the SIP usage of STUN > keep-alive can then of course refer to that text in 3849bis. It would be more appropriate in the keepalive usage section. > My main concern is that we dont specify things which people will > later find out belongs to another spec, and another WG. My concern is that if you stop doing STUN keepalives because you haven't received a response in NNNN retransmissions, your NAT binding will time out soon thereafter. So here is some proposed text for the RFC3489bis keepalive section: If, after retransmitting the STUN Binding Request NNNN times, the STUN client does not receive a STUN Binding Response, the STUN client should assume the STUN server is no longer available. The STUN client SHOULD cease retransmitting the STUN keepalives and inform other applications that the NAT binding is no longer valid (e.g., attempt to re-register if using SIP). -d _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 15 20:20:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD97e-0004pn-L2; Tue, 15 Aug 2006 20:19:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD97d-0004ph-9l for sip@ietf.org; Tue, 15 Aug 2006 20:19:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD97b-0002mi-0m for sip@ietf.org; Tue, 15 Aug 2006 20:19:01 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 15 Aug 2006 17:18:58 -0700 X-IronPort-AV: i="4.08,129,1154934000"; d="scan'208"; a="311799771:sNHT30710584" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7G0IwVA019845; Tue, 15 Aug 2006 17:18:58 -0700 Received: from dwingwxp (sjc-vpn4-518.cisco.com [10.21.82.6]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7G0IvSl028420; Tue, 15 Aug 2006 17:18:57 -0700 (PDT) From: "Dan Wing" To: "'Rohan Mahy'" , "'Christer Holmberg \(JO/LMF\)'" Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Tue, 15 Aug 2006 17:18:49 -0700 Message-ID: <063601c6c0c9$8f83d920$0652150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Aca/s/gnXiz6ksDtT2GHfzDe8ZuKzgBFT0OA In-Reply-To: <8256efd72d64f8b36660161d9447c02d@ekabal.com> DKIM-Signature: a=rsa-sha1; q=dns; l=1029; t=1155687538; x=1156551538; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[Sip]=20Outbound=20-=20a=20new=20STUN=20keealive=20proposal; X=v=3Dcisco.com=3B=20h=3DAikrTB3w+Q+lGAQyxSJvTzUBl8E=3D; b=Bsk2kX3OK2+hJTTWX7fa1oLmlIYkuLiQAvKOsVyu6LelSz2A6akHivuuJ/mISulzJFofTK3j dxFCYcercmEfcjp/0kXQJWSo/ngwZB31uynMGA5IoDRLF2ydWi7musrB; Authentication-Results: sj-dkim-5.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'SIP' , 'Cullen Jennings' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > 1. Editorial: Shouldn't the > > stop-sending-STUN-requests-if-retransmissions-fail text > > (point 2) be in > > 3849bis? To me it sounds like generic STUN transaction procedures, > > which should be defined in the STUN spec. Or, do we consider it > > specific to the STUN keepalive usage for SIP??? > > I don't think this is generic STUN procedures. There are reasons why > you need to have different transmission policies. For example ICE > would not work if we SIP STUN keepalive style restrictions on it. ICE uses the Connectivity Check usage (*), whereas sip-outbound is using the Keepalive usage. So as long as Christer's suggested text is only associated with RFC3489bis's Keepalive usage I think we're safe. (*) The only time ICE uses the Keepalive usage is where ICE suggests that something is needed to keep NAT bindings alive if media isn't being actively transmitted, and ICE suggests using the keepalive usage, a 'silence packet', an RTP NoOp packet, etc. -d _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 15 20:22:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD99U-0005Ma-Ju; Tue, 15 Aug 2006 20:20:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD99U-0005MV-00 for sip@ietf.org; Tue, 15 Aug 2006 20:20:56 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD99S-00038O-Jd for sip@ietf.org; Tue, 15 Aug 2006 20:20:55 -0400 Received: (from apache@localhost) by figas.ekabal.com (8.11.6/8.11.6) id k7G0KaD17886; Tue, 15 Aug 2006 17:20:36 -0700 From: Rohan Mahy X-Authentication-Warning: figas.ekabal.com: apache set sender to rohan@localhost using -f Received: from 12.151.41.2 (SquirrelMail authenticated user rohan); by figas.ekabal.com with HTTP; Tue, 15 Aug 2006 17:20:36 -0700 (PDT) Message-ID: <18997.12.151.41.2.1155687636.squirrel@12.151.41.2> In-Reply-To: <063501c6c0c9$36fdf3d0$0652150a@amer.cisco.com> References: <5EB80D22825EEE42872083AD5BFFB594017F134B@esealmw113.eemea.ericsson.se> <063501c6c0c9$36fdf3d0$0652150a@amer.cisco.com> Date: Tue, 15 Aug 2006 17:20:36 -0700 (PDT) Subject: RE: [Sip] Outbound - a new STUN keealive proposal To: "Dan Wing" User-Agent: SquirrelMail/1.4.3a-1 X-Mailer: SquirrelMail/1.4.3a-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 'Cullen Jennings' , 'SIP' , 'Rohan Mahy' , ietf-behave@list.sipfoundry.org, 'Christer Holmberg ' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I think this is a slippery slope for 3489bis. I can think of about 3 use cases that would break, or at least would be confusing, with this wording. I would like some time to propose language specific to SIP and STUN on the same port that is appropriate. thanks, -rohan >> >> 1. Editorial: Shouldn't the >> >> stop-sending-STUN-requests-if-retransmissions-fail text (point >> >> 2) be in 3849bis? To me it sounds like generic STUN >> >> transaction procedures, which should be defined in the STUN >> >> spec. Or, do we consider it specific to the STUN keepalive >> >> usage for SIP??? >> > >> >Propose some text - as much as the advice can be made generic, I >> >would want it to be in 3849bis. I suspect it hard to say too much >> >more than what is in 3849. >> >> I need to think a little more about this a little bit more. >> >> Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, >> and when a transaction shall be considered to have failed. But, >> there is no text about what happens after that. THAT may be STUN >> usage dependent, though, and in some cases it could even be "an >> implementation issue"... >> >> But, I don't see anything SIP specific in saying that STUN >> keep-alive re-transmissions shall stop if there is no reply, so >> shouldn't that text be in 3849bis - either in the generic >> transaction chapter (chapter 7), or in the keep-alive usage chapter >> (12.4)? The part of the outbound spec defining the SIP usage of STUN >> keep-alive can then of course refer to that text in 3849bis. > > It would be more appropriate in the keepalive usage section. > >> My main concern is that we dont specify things which people will >> later find out belongs to another spec, and another WG. > > My concern is that if you stop doing STUN keepalives because you > haven't received a response in NNNN retransmissions, your NAT > binding will time out soon thereafter. So here is some proposed text > for the RFC3489bis keepalive section: > > If, after retransmitting the STUN Binding Request NNNN times, > the STUN client does not receive a STUN Binding Response, the > STUN client should assume the STUN server is no longer > available. The STUN client SHOULD cease retransmitting the > STUN keepalives and inform other applications that the NAT > binding is no longer valid (e.g., attempt to re-register if > using SIP). > > -d > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 01:06:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDDY0-00038P-12; Wed, 16 Aug 2006 01:02:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDDXy-000389-Hs for sip@ietf.org; Wed, 16 Aug 2006 01:02:30 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDDXw-0007Sk-4P for sip@ietf.org; Wed, 16 Aug 2006 01:02:30 -0400 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7G54dGD019960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Aug 2006 00:04:40 -0500 Message-ID: <44E2A709.6030502@softarmor.com> Date: Wed, 16 Aug 2006 00:03:05 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Paul Kyzivat , IETF SIP List Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 References: <20060814021814.B719A222425@laser.networkresonance.com> <44E24269.7060604@cisco.com> In-Reply-To: <44E24269.7060604@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > Eric raised a lot of issues. I've been waiting to see Jonathan's > response. Meanwhile I'll try to add my opinion about a couple of them. > > Paul > > Eric Rescorla wrote: > >> Why is it necessary to have GRUUs which are (1) identifiable >> as GRUUs to peers but (2) can't be translated back to the AOR >> by the peer? > > A use case might help here: > > - Bob has an "unlisted" AOR. > - Alice calls Bob. (She knows the AOR.) > - Alice does a transfer, > transferring Charlie to Bob, replacing Alice:Bob call > > To do this, Alice sends a REFER to Charlie, with a Refer-To containing > the contact URI from her dialog with Bob. > > Bob doesn't want Charlie to be able to learn his AOR as a result of > this. If Bob uses a gruu obtained from the registrar for his AOR, he > doesn't want Charlie to be able to reconstruct the AOR from it. But why does Charlie need to be able to tell that the URI he has for Bob is a GRUU? I've been wondering about this since day one, and nobody could ever tell me, so I just stopped asking hoping it would eventually make sense. Of course, it could just be that I'm being overly dense but I still wonder why we need this property. OTOH "knowing it is a GRUU" precludes some of the security benefits. I've always thought that GRUus should just be URIs that can serve as contact-specific aliases, but not be "obviously" aliases. It's like a few years back when the US congress tried to make privately-operated mail delivery boxes have special "PMB" labels, so that everybody would know the destination was a drop box and not a "real" destination. As a consequence, I couldn't get package deliveries, because none of the mail-order computer places would ship to a "PMB" (even though there was a paid attendant there to sign for things, with better security by far than my rented office-suite in the office-hotel) on the assumption that only criminals would try to hide their "real" addresses behind a PMB alias. Will applications (or users) discriminate against GRUUs since they are "obviously less traceable than real AORs?" Will people demand an "anonymous REFER-target request rejection service"? > > Note that the peer (Alice) that first receives this gruu knows what AOR > it is associated with, because she called it. This correlation is not > available when the request gets to another peer - Charlie. > >> However, forwarding services, such as call forwarding, SHOULD NOT be >> provided for requests sent to a GRUU. The intent of the GRUU is to >> target a specific UA instance, and this is incompatible with >> forwarding operations. >> >> This seems to me to get into policy. Are you saying that I can't >> have my cell phone forward calls to some other phone just cause >> people call my cell number rather than my generic "EKR" AOR? > > One intent of a gruu is to identify a specific UA instance. A service > that ignores that intent will in general be counter productive. > > But this is a gray area, and so it is hard to state a precise yet > general rule that can be used to decide whether a particular service > should be applied to a request targeting a gruu. I think all the draft > can do is sensitize developers to the issue, so that they think > carefully about it regarding each service. Again, I've long suspected we've built a house of cards. here. Not enough to justify not building it, but enough to make me wonder why. Although I do have real worries that we have more complexity developing here (and in the remainder of SIP-land) than we really need. If a "GRUU" were an aliased URI, and the thing that it aliases refers to something that will be expanded by forking or redirection, then any service that will break with forking (or expansion by redirection) will break when used with that "GRUU". What more do we need to say than "Don't use forking or expansion by redirection on something that really needs to be a Contact-specific reference, dude!" Sure, the thing to which a Contact-specific reference is assigned needs to know that the reference is Contact-specific. And the thing assigning the reference needs to know this too. But does everybody else? And if they do, do we need a syntactic way to say that some other URI (which might also happen to be an AOR) has the Contact-specific property (aka foreknowledge that it will not be forked or recursed) so that things can treat it like they would a GRUU? Will proxy-forwarding on a GRUU work? Yes, it appears to work in all cases, provided that the forwarding is to a single destination such as another GRUU or any URI that just doesn't expand and continues to reach the same destination for as long as that URI is valid. Will forking of a request that was targeted to a GRUU work? Probably not, or at least not without a high probability of a surprising failure. More specifically, it seems to me that the GRUU model mixes up AOR-specific aliases, contact-specific aliases, and suppression of contact forking and expansion in a rather convoluted fashion. the current documentation is an amazing piece of work, but it shouldn't have had to have been. This should have been much, much easier, and the fact that it isn't tells me we went wrong somewhere. Could we boil things down to a simple ruleset that says "Start communications with any AOR.Continue them using a Contact or Contact-specific alias. Remember that merging two communications together (as in a transfer) is a continuation of both communications, so use a Contact or Contact-specific aliases there too." Of course, we also need a way to assign a Contact-specific alias, which would seem easy enough to do in a REGISTER response. So why does this draft need to be 40 pages long? -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 01:27:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDDtm-0001Wi-2f; Wed, 16 Aug 2006 01:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDDtk-0001Wb-9a for sip@ietf.org; Wed, 16 Aug 2006 01:25:00 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDDtf-00008i-Q1 for sip@ietf.org; Wed, 16 Aug 2006 01:25:00 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 16 Aug 2006 07:24:14 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Aug 2006 07:24:13 +0200 Message-Id: <85108216918A984C8C60172D7C84770A56F60D@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: "Jesske, R" , jdrosen@cisco.com, sip@ietf.org Subject: AW: [Sip] updated acr code draft Date: Wed, 16 Aug 2006 07:24:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: esasaki@NTT-AT.COM X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm sorry to treat you, but there is still no clarification on this = issue. Best Regards Roland Jesske > -----Urspr=FCngliche Nachricht----- > Von: Jesske, Roland=20 > Gesendet: Dienstag, 1. August 2006 07:25 > An: 'Jonathan Rosenberg'; IETF SIP List > Betreff: AW: [Sip] updated acr code draft >=20 >=20 > In this Draft is described that: > The request contained a Privacy header field whose value was 'id' > [3] or 'user'. This explicitly excludes the 'header' and > 'session' privacy services, since those do not directly=20 > convey the > identity of the requestor. >=20 > Why the value 'header ' is exluded?=20 >=20 > In RFC3323 is described that header: > header: The user requests that a privacy service obscure those > headers which cannot be completely expunged of identifying > information without the assistance of intermediaries=20 > (such as Via > and Contact). Also, no unnecessary headers should be=20 > added by the > service that might reveal personal information about the > originator of the request. >=20 > So from my understanding 'id' is a subset of 'header' because=20 > the P-Asserted-Identity can only be deleted by untermediarities. >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Gesendet: Montag, 31. Juli 2006 22:31 > An: IETF SIP List > Betreff: [Sip] updated acr code draft >=20 >=20 > I've submitted a minor update to the ACR code draft. Until it=20 > appears,=20 > you can pick it up at: >=20 > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt >=20 > the changes are: >=20 > * replaced P-Asserted-ID with P-Asserted-Identity >=20 > * added to security considerations section, consideration > for anonymizers in the network. Namely, don't retry > request on receipt of 433 unless explicitly configured > to do so by user >=20 >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.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=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 01:49:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDEEr-00086M-06; Wed, 16 Aug 2006 01:46:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDEEp-00084k-Fm for sip@ietf.org; Wed, 16 Aug 2006 01:46:47 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDEEo-0002JL-5b for sip@ietf.org; Wed, 16 Aug 2006 01:46:47 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 3F0431E8C1C; Tue, 15 Aug 2006 22:46:43 -0700 (PDT) To: Dean Willis Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 References: <20060814021814.B719A222425@laser.networkresonance.com> <44E24269.7060604@cisco.com> <44E2A709.6030502@softarmor.com> From: Eric Rescorla Date: Tue, 15 Aug 2006 22:46:43 -0700 In-Reply-To: <44E2A709.6030502@softarmor.com> (Dean Willis's message of "Wed, 16 Aug 2006 00:03:05 -0500") Message-ID: <86y7tp6xmk.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > Paul Kyzivat wrote: >> Eric raised a lot of issues. I've been waiting to see Jonathan's >> response. Meanwhile I'll try to add my opinion about a couple of >> them. >> Paul >> Eric Rescorla wrote: >> >>> Why is it necessary to have GRUUs which are (1) identifiable >>> as GRUUs to peers but (2) can't be translated back to the AOR >>> by the peer? >> A use case might help here: >> - Bob has an "unlisted" AOR. >> - Alice calls Bob. (She knows the AOR.) >> - Alice does a transfer, >> transferring Charlie to Bob, replacing Alice:Bob call >> To do this, Alice sends a REFER to Charlie, with a Refer-To >> containing the contact URI from her dialog with Bob. >> Bob doesn't want Charlie to be able to learn his AOR as a result of >> this. If Bob uses a gruu obtained from the registrar for his AOR, he >> doesn't want Charlie to be able to reconstruct the AOR from it. > > But why does Charlie need to be able to tell that the URI he has for > Bob is a GRUU? I've been wondering about this since day one, and > nobody could ever tell me, so I just stopped asking hoping it would > eventually make sense. Of course, it could just be that I'm being > overly dense but I still wonder why we need this property. This is the question I meant to be asking as well... -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 02:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFK8-0002AF-Gn; Wed, 16 Aug 2006 02:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFK7-0002AA-0N for sip@ietf.org; Wed, 16 Aug 2006 02:56:19 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDFK5-0007e5-Li for sip@ietf.org; Wed, 16 Aug 2006 02:56:18 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2C3AB6E0002; Wed, 16 Aug 2006 08:55:20 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:55:19 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:55:19 +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 Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Wed, 16 Aug 2006 08:55:18 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1350@esealmw113.eemea.ericsson.se> In-Reply-To: <063601c6c0c9$8f83d920$0652150a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound - a new STUN keealive proposal Thread-Index: Aca/s/gnXiz6ksDtT2GHfzDe8ZuKzgBFT0OAAA3I16A= From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , "Rohan Mahy" X-OriginalArrivalTime: 16 Aug 2006 06:55:19.0235 (UTC) FILETIME=[EFB40130:01C6C100] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan is correct - I am only talking about the STUN keep-alive usage. Regards, Christer=20 -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: 16. elokuuta 2006 3:19 To: 'Rohan Mahy'; Christer Holmberg (JO/LMF) Cc: 'SIP'; 'Cullen Jennings' Subject: RE: [Sip] Outbound - a new STUN keealive proposal > > 1. Editorial: Shouldn't the > > stop-sending-STUN-requests-if-retransmissions-fail text (point 2) be > > in 3849bis? To me it sounds like generic STUN transaction=20 > > procedures, which should be defined in the STUN spec. Or, do we=20 > > consider it specific to the STUN keepalive usage for SIP??? >=20 > I don't think this is generic STUN procedures. There are reasons why=20 > you need to have different transmission policies. For example ICE=20 > would not work if we SIP STUN keepalive style restrictions on it. ICE uses the Connectivity Check usage (*), whereas sip-outbound is using the Keepalive usage. So as long as Christer's suggested text is only associated with RFC3489bis's Keepalive usage I think we're safe. (*) The only time ICE uses the Keepalive usage is where ICE=20 suggests that something is needed to keep NAT bindings alive=20 if media isn't being actively transmitted, and ICE suggests=20 using the keepalive usage, a 'silence packet', an RTP NoOp=20 packet, etc. -d _______________________________________________ Sip mailing list https://www1.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 curFrom sip-bounces@ietf.org Wed Aug 16 02:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFK8-0002AF-Gn; Wed, 16 Aug 2006 02:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFK7-0002AA-0N for sip@ietf.org; Wed, 16 Aug 2006 02:56:19 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDFK5-0007e5-Li for sip@ietf.org; Wed, 16 Aug 2006 02:56:18 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2C3AB6E0002; Wed, 16 Aug 2006 08:55:20 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:55:19 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:55:19 +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 Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Wed, 16 Aug 2006 08:55:18 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1350@esealmw113.eemea.ericsson.se> In-Reply-To: <063601c6c0c9$8f83d920$0652150a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound - a new STUN keealive proposal Thread-Index: Aca/s/gnXiz6ksDtT2GHfzDe8ZuKzgBFT0OAAA3I16A= From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , "Rohan Mahy" X-OriginalArrivalTime: 16 Aug 2006 06:55:19.0235 (UTC) FILETIME=[EFB40130:01C6C100] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan is correct - I am only talking about the STUN keep-alive usage. Regards, Christer=20 -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: 16. elokuuta 2006 3:19 To: 'Rohan Mahy'; Christer Holmberg (JO/LMF) Cc: 'SIP'; 'Cullen Jennings' Subject: RE: [Sip] Outbound - a new STUN keealive proposal > > 1. Editorial: Shouldn't the > > stop-sending-STUN-requests-if-retransmissions-fail text (point 2) be > > in 3849bis? To me it sounds like generic STUN transaction=20 > > procedures, which should be defined in the STUN spec. Or, do we=20 > > consider it specific to the STUN keepalive usage for SIP??? >=20 > I don't think this is generic STUN procedures. There are reasons why=20 > you need to have different transmission policies. For example ICE=20 > would not work if we SIP STUN keepalive style restrictions on it. ICE uses the Connectivity Check usage (*), whereas sip-outbound is using the Keepalive usage. So as long as Christer's suggested text is only associated with RFC3489bis's Keepalive usage I think we're safe. (*) The only time ICE uses the Keepalive usage is where ICE=20 suggests that something is needed to keep NAT bindings alive=20 if media isn't being actively transmitted, and ICE suggests=20 using the keepalive usage, a 'silence packet', an RTP NoOp=20 packet, etc. -d _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 02:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFJL-00025g-JY; Wed, 16 Aug 2006 02:55:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFJL-00025Y-0S for sip@ietf.org; Wed, 16 Aug 2006 02:55:31 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDFJA-0007b2-Br for sip@ietf.org; Wed, 16 Aug 2006 02:55:30 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3F5304F0193; Wed, 16 Aug 2006 08:55:09 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:55:08 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:55: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 Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Wed, 16 Aug 2006 08:55:07 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F134F@esealmw113.eemea.ericsson.se> In-Reply-To: <18997.12.151.41.2.1155687636.squirrel@12.151.41.2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound - a new STUN keealive proposal Thread-Index: AcbAyd0ZsErhbFVYTYqplv+LhLuSLgANqhQg From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" , "Dan Wing" X-OriginalArrivalTime: 16 Aug 2006 06:55:08.0517 (UTC) FILETIME=[E9509150:01C6C100] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Cullen Jennings , SIP , ietf-behave@list.sipfoundry.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, We could write something like: "If the STUN binding transaction fails, as described in 3489, the SIP UA must/may/could/must not do this-and-that-SIP-procedure". I have nothing against putting SIP specific actions into the outbound draft, but anything that can be considered to be generic to STUN keepalive usage should be in 3489bis. Regards, Christer=20 -----Original Message----- From: Rohan Mahy [mailto:rohan@ekabal.com]=20 Sent: 16. elokuuta 2006 3:21 To: Dan Wing Cc: Christer Holmberg (JO/LMF); 'Cullen Jennings'; 'SIP'; 'Rohan Mahy'; ietf-behave@list.sipfoundry.org Subject: RE: [Sip] Outbound - a new STUN keealive proposal Hi, I think this is a slippery slope for 3489bis. I can think of about 3 use cases that would break, or at least would be confusing, with this wording. I would like some time to propose language specific to SIP and STUN on the same port that is appropriate. thanks, -rohan >> >> 1. Editorial: Shouldn't the >> >> stop-sending-STUN-requests-if-retransmissions-fail text (point >> >> 2) be in 3849bis? To me it sounds like generic STUN >> >> transaction procedures, which should be defined in the STUN >> >> spec. Or, do we consider it specific to the STUN keepalive >> >> usage for SIP??? >> > >> >Propose some text - as much as the advice can be made generic, I=20 >> >would want it to be in 3849bis. I suspect it hard to say too much=20 >> >more than what is in 3849. >> >> I need to trent sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 16 02:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFJL-00025g-JY; Wed, 16 Aug 2006 02:55:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFJL-00025Y-0S for sip@ietf.org; Wed, 16 Aug 2006 02:55:31 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDFJA-0007b2-Br for sip@ietf.org; Wed, 16 Aug 2006 02:55:30 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3F5304F0193; Wed, 16 Aug 2006 08:55:09 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:55:08 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:55: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 Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Wed, 16 Aug 2006 08:55:07 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F134F@esealmw113.eemea.ericsson.se> In-Reply-To: <18997.12.151.41.2.1155687636.squirrel@12.151.41.2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound - a new STUN keealive proposal Thread-Index: AcbAyd0ZsErhbFVYTYqplv+LhLuSLgANqhQg From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" , "Dan Wing" X-OriginalArrivalTime: 16 Aug 2006 06:55:08.0517 (UTC) FILETIME=[E9509150:01C6C100] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Cullen Jennings , SIP , ietf-behave@list.sipfoundry.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, We could write something like: "If the STUN binding transaction fails, as described in 3489, the SIP UA must/may/could/must not do this-and-that-SIP-procedure". I have nothing against putting SIP specific actions into the outbound draft, but anything that can be considered to be generic to STUN keepalive usage should be in 3489bis. Regards, Christer=20 -----Original Message----- From: Rohan Mahy [mailto:rohan@ekabal.com]=20 Sent: 16. elokuuta 2006 3:21 To: Dan Wing Cc: Christer Holmberg (JO/LMF); 'Cullen Jennings'; 'SIP'; 'Rohan Mahy'; ietf-behave@list.sipfoundry.org Subject: RE: [Sip] Outbound - a new STUN keealive proposal Hi, I think this is a slippery slope for 3489bis. I can think of about 3 use cases that would break, or at least would be confusing, with this wording. I would like some time to propose language specific to SIP and STUN on the same port that is appropriate. thanks, -rohan >> >> 1. Editorial: Shouldn't the >> >> stop-sending-STUN-requests-if-retransmissions-fail text (point >> >> 2) be in 3849bis? To me it sounds like generic STUN >> >> transaction procedures, which should be defined in the STUN >> >> spec. Or, do we consider it specific to the STUN keepalive >> >> usage for SIP??? >> > >> >Propose some text - as much as the advice can be made generic, I=20 >> >would want it to be in 3849bis. I suspect it hard to say too much=20 >> >more than what is in 3849. >> >> I need to think a little more about this a little bit more. >> >> Chapter 7.1 of 3849bis does talk about STUN re-transimission timers,=20 >> and when a transaction shall be considered to have failed. But,=20 >> there is no text about what happens after that. THAT may be STUN=20 >> usage dependent, though, and in some cases it could even be "an=20 >> implementation issue"... >> >> But, I don't see anything SIP specific in saying that STUN keep-alive >> re-transmissions shall stop if there is no reply, so shouldn't that=20 >> text be in 3849bis - either in the generic transaction chapter=20 >> (chapter 7), or in the keep-alive usage chapter (12.4)? The part of=20 >> the outbound spec defining the SIP usage of STUN keep-alive can then=20 >> of course refer to that text in 3849bis. > > It would be more appropriate in the keepalive usage section. > >> My main concern is that we dont specify things which people will=20 >> later find out belongs to another spec, and another WG. > > My concern is that if you stop doing STUN keepalives because you=20 > haven't received a response in NNNN retransmissions, your NAT binding=20 > will time out soon thereafter. So here is some proposed text for the=20 > RFC3489bis keepalive section: > > If, after retransmitting the STUN Binding Request NNNN times, > the STUN client does not receive a STUN Binding Response, the > STUN client should assume the STUN server is no longer > available. The STUN client SHOULD cease retransmitting the > STUN keepalives and inform other applications that the NAT > binding is no longer valid (e.g., attempt to re-register if > using SIP). > > -d > _______________________________________________ Sip mailing list https://www1.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 hink a little more about this a little bit more. >> >> Chapter 7.1 of 3849bis does talk about STUN re-transimission timers,=20 >> and when a transaction shall be considered to have failed. But,=20 >> there is no text about what happens after that. THAT may be STUN=20 >> usage dependent, though, and in some cases it could even be "an=20 >> implementation issue"... >> >> But, I don't see anything SIP specific in saying that STUN keep-alive >> re-transmissions shall stop if there is no reply, so shouldn't that=20 >> text be in 3849bis - either in the generic transaction chapter=20 >> (chapter 7), or in the keep-alive usage chapter (12.4)? The part of=20 >> the outbound spec defining the SIP usage of STUN keep-alive can then=20 >> of course refer to that text in 3849bis. > > It would be more appropriate in the keepalive usage section. > >> My main concern is that we dont specify things which people will=20 >> later find out belongs to another spec, and another WG. > > My concern is that if you stop doing STUN keepalives because you=20 > haven't received a response in NNNN retransmissions, your NAT binding=20 > will time out soon thereafter. So here is some proposed text for the=20 > RFC3489bis keepalive section: > > If, after retransmitting the STUN Binding Request NNNN times, > the STUN client does not receive a STUN Binding Response, the > STUN client should assume the STUN server is no longer > available. The STUN client SHOULD cease retransmitting the > STUN keepalives and inform other applications that the NAT > binding is no longer valid (e.g., attempt to re-register if > using SIP). > > -d > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 02:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFKF-0002BC-BN; Wed, 16 Aug 2006 02:56:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFKE-0002B6-9z for sip@ietf.org; Wed, 16 Aug 2006 02:56:26 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDFK5-0007e4-Li for sip@ietf.org; Wed, 16 Aug 2006 02:56:26 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F3AE58E0001; Wed, 16 Aug 2006 08:55:28 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:55:28 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:55:28 +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 Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Wed, 16 Aug 2006 08:55:27 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1351@esealmw113.eemea.ericsson.se> In-Reply-To: <063501c6c0c9$36fdf3d0$0652150a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound - a new STUN keealive proposal Thread-Index: AcbAJlsJCNXDRm04SXe16hJYaQZ6XwAhyqoQAAatv8AADdhBAA== From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , "Cullen Jennings" X-OriginalArrivalTime: 16 Aug 2006 06:55:28.0438 (UTC) FILETIME=[F5304560:01C6C100] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: SIP , Rohan Mahy , ietf-behave@list.sipfoundry.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>> 1. Editorial: Shouldn't the >>>> stop-sending-STUN-requests-if-retransmissions-fail text (point >>>> 2) be in 3849bis? To me it sounds like generic STUN >>>> transaction procedures, which should be defined in the STUN >>>> spec. Or, do we consider it specific to the STUN keepalive >>>> usage for SIP??? >>> >>>Propose some text - as much as the advice can be made generic, I=20 >>>would want it to be in 3849bis. I suspect it hard to say too much=20 >>>more than what is in 3849. >> >>I need to think a little more about this a little bit more. >> >>Chapter 7.1 of 3849bis does talk about STUN re-transimission timers,=20 >>and when a transaction shall be considered to have failed. But, there >>is no text about what happens after that. THAT may be STUN usage=20 >>dependent, though, and in some cases it could even be "an=20 >>implementation issue"... >> >>But, I don't see anything SIP specific in saying that STUN keep-alive=20 >>re-transmissions shall stop if there is no reply, so shouldn't that=20 >>text be in 3849bis - either in the generic transaction chapter=20 >>(chapter 7), or in the keep-alive usage chapter (12.4)? The part of=20 >>the outbound spec defining the SIP usage of STUN keep-alive can then=20 >>of course refer to that text in 3849bis. > >It would be more appropriate in the keepalive usage section. > >>My main concern is that we dont specify things which people will later >>find out belongs to another spec, and another WG. > >My concern is that if you stop doing STUN keepalives because you haven't received a response in NNNN retransmissions,=20 >your NAT binding will time out soon thereafter. So here is some proposed text for the RFC3489bis keepalive section: > > If, after retransmitting the STUN Binding Request NNNN times, > the STUN client does not receive a STUN Binding Response, the > STUN client should assume the STUN server is no longer > available. The STUN client SHOULD cease retransmitting the > STUN keepalives and inform other applications that the NAT > binding is no longer valid (e.g., attempt to re-register if > using SIP). I don't think we need to talk about NNNN times. Can't we simply say "If the STUN client does not receive a response, and the STUN transaction fails, the STUN client should assume....". Then, IF we want to talk about SIP actions taken due to the failure (re-registers etc), THAT belongs to a SIP specific spec I think. Regards, Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 04:28:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDGiP-0005wg-LD; Wed, 16 Aug 2006 04:25:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDGiN-0005wT-MC; Wed, 16 Aug 2006 04:25:27 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDGiL-0006kn-8G; Wed, 16 Aug 2006 04:25:27 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 03:25:20 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 16 Aug 2006 03:25:20 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 03:25:19 -0500 Message-ID: From: "Dawson, Martin" To: "Drage, Keith \(Keith\)" , "Andrew Newton" , "Winterbottom, James" Date: Wed, 16 Aug 2006 03:25:17 -0500 Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have anHTTPdereferencemechanism defined MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 16 Aug 2006 08:25:19.0840 (UTC) FILETIME=[82B6EE00:01C6C10D] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <5D1A7985295922448D5550C94DE29180278FD6@DEEXC1U01.de.lucent.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Does Location-Conveyance have anHTTPdereferencemechanism defined Thread-Index: Aca1B+ZeLLsjYFmHQQ2U8yRlbuTwXgAIJqCAAtvtv1AAHNzGYA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: IETF SIP List , "Rosen, Brian" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Keith, 1. I disagree that a HTTP URI indicates anything about the using protocol other than the transport it uses. HTTP is the transport. A SIP URI could equally indicate a SIP transport but with a set of protocol semantics that do not honor the geopriv requirements. 2. No - as above - the reference URI does not convey information about the nature of the user protocol that the referenced server is going to support. Also, even if the URI did indicate the nature of the using protocol, it is not appropriate to have to continually update a SIP document every time a new geopriv compliant user protocol is invented. The SIP conveyance cannot assure anything about the integrity of the using protocol supported by the referenced server and it should not imply that it can. Services that are provided for the purpose of location object conveyance will need to be assessed themselves as to whether they meet the geopriv constraints. 3. I think geopriv could maintain a document of *actual using protocols* that are considered to meet the geopriv constraints. Noting that listing the actual protocols also conveys more than the type of URI that could be used to reference a server supporting those protocols. At least, then, there would be a single place to maintain this information and the SIP specification can simply state that the URI, whatever its form, must be a reference to a server which supports a using protocol that honors geopriv constraints - as could every one of the other protocols that I would certainly hope are going to be able to convey a location reference - and without having to be updated every time a new using protocol is defined. Cheers, Martin > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, 16 August 2006 4:32 AM > To: Dawson, Martin; Andrew Newton; Winterbottom, James > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have > anHTTPdereferencemechanism defined >=20 > I must admit I am still having trouble working out what your position, > and that of Henning and James W. is. >=20 > 1) The dereferencing protocol is a using protocol according to the > GEOPRIV RFCs. I assume that GEOPRIV is therefore going to require that > such a using protocol meets their requirements. HTTP in its current form > does not meet those requirements. Is there anything here you disagree > with? >=20 > 2) So then we get to the step of should the URI conveyance police > the using protocol that can be used, which is essentially what Brian is > proposing. I certainly understand that it should be policed somewhere, > and if it is not policed by the syntax of the protocol, it either has to > be policed by the dereferencer, or by the location provider itself. > Where do you stand on this? To me it seems automatic to police it by the > types of URI that are allowed to be used, and therefore I need to > understand how you see this. >=20 > 3) If you agree that we police by the types of URI to be used, is > the problem here then that GEOPRIV rather than SIP should write the > document that makes these constraints? >=20 > Regards >=20 > Keith >=20 >=20 >=20 > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: 01 August 2006 06:14 > > To: Andrew Newton; Winterbottom, James > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance > > have anHTTPdereferencemechanism defined > > > > I'm OK as long as the ABNF includes the AbsoluteURI option > > and the text does not say anything specifically about > > excluding HTTP (or any other form of URI). > > > > I've attempted to point out previously that the URI doesn't > > actually convey anything about whether the geopriv rules are > > going to be respected or not. It's actually a geopriv rule > > that those rules be respected so it's superfluous, and out of > > scope, to also require the statement in a SIP conveyance document. > > > > AbsoluteURI as a generic form, encompasses sip etc. anyway, > > so it's also superfluous to include those in the ABNF. > > However, it's also a harmless waste of space. If Brian is > > keen to include them for some reason, and as long as neither > > the text nor the ABNF bias the specification toward those > > forms in any way, then there are certainly better things to > > lose sleep over. > > > > Cheers, > > Martin > > > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Tuesday, 1 August 2006 11:15 AM > > > To: Winterbottom, James > > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > > Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an > > > HTTPdereferencemechanism defined > > > > > > > > > On Jul 31, 2006, at 9:11 PM, Winterbottom, James wrote: > > > > > > > Hi Andy, > > > > > > > > That is all I have asked for, do not constrain the ABNF. > > If "how I > > > > use HTTP as a reference" goes in a different document > > that is fine > > > > providing the ABNF is not constrained in the conveyance > > > > specification. This is not how I read Brian's statement below: > > > > > > > > "This is NOT the discussion of what the ABNF of the > > location header > > > > looks like (although it would NOT have http/https in it > > for sure if > > > > we > > agree > > > > that an HTTP dereference protocol is a separate draft)." > > > > > > > > Which to me clearly says the ABNF will be restrict to > > exclude HTTP/ > > > > HTTPS if there is agreement that the conveyance draft > > doesn't have > > > > specific text on how to deference an HTTP reference. > > > > > > > > Cheers > > > > James > > > > > > Please keep in mind that this does not stop the draft from > > using MUST/ > > > SHOULD language from stipulating "the URI MUST be a GEOPRIV > > standards > > > track using protocol." > > > > > > -andy > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 08:52:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDKoI-0007HT-Ez; Wed, 16 Aug 2006 08:47:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDKoG-0007HO-N1 for sip@ietf.org; Wed, 16 Aug 2006 08:47:48 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDKoE-0006OX-DS for sip@ietf.org; Wed, 16 Aug 2006 08:47:48 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 16 Aug 2006 08:47:46 -0400 X-IronPort-AV: i="4.08,132,1154923200"; d="scan'208"; a="97073204:sNHT32454368" 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.20060308/8.12.11) with ESMTP id k7GClkk9022250; Wed, 16 Aug 2006 08:47:46 -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.12.10/8.12.6) with ESMTP id k7GCljuI000613; Wed, 16 Aug 2006 08:47:45 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:47:44 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:47:44 -0400 Message-ID: <44E313F0.9010603@cisco.com> Date: Wed, 16 Aug 2006 08:47:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 References: <20060814021814.B719A222425@laser.networkresonance.com> <44E24269.7060604@cisco.com> <44E2A709.6030502@softarmor.com> <86y7tp6xmk.fsf@raman.networkresonance.com> <44E2C75C.6090300@cisco.com> In-Reply-To: <44E2C75C.6090300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2006 12:47:44.0359 (UTC) FILETIME=[2B2DDF70:01C6C132] DKIM-Signature: a=rsa-sha1; q=dns; l=2057; t=1155732466; x=1156596466; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-ietf-sip-gruu-10 |To:Jonathan=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3DIhYcytQwHYv3ZD0NF3ad3b/43PQ=3D; b=C7fR6fP17lZwR9HHVC2lfffNFFlf3ELl0pZtED0jFeDAAxGxTWxO7dqb3GSfYDlPusWfjrz4 qXNQug8y5rf6s+YtjqtamgEGqxl036KhnOztnDoEdOhJCH0H5C2F2R1D; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Adding to what Jonathan said: This is at least in part a work around because implementations of sip have been violating 3261. 3261 says that Contact URIs must be globally routable, but in practice they rarely have been. When they don't have that property, then they can't be used directly for features like transfer. So various other work-arounds have been evolved, such as Jonathan mentions. These aren't reliable, but are better than nothing. When gruus are available, it becomes possible for UAs to offer contact addresses that conform to 3261, and hence allow others to use those contact addresses to implement features using them. But, since UAs that don't use gruus are still ubiquitous, there needs to be some way for a UA carrying out a feature to know if the contact provided by a peer is globally routable. The hack is to simply mark it as such. Paul Jonathan Rosenberg wrote: > I'll reply to Eric's comments individually asap, but one quick response > below: > > Eric Rescorla wrote: > >>> But why does Charlie need to be able to tell that the URI he has for >>> Bob is a GRUU? I've been wondering about this since day one, and >>> nobody could ever tell me, so I just stopped asking hoping it would >>> eventually make sense. Of course, it could just be that I'm being >>> overly dense but I still wonder why we need this property. >> >> >> This is the question I meant to be asking as well... > > The reason you need to be able to tell that the URI is a gruu, is that > if its not a gruu, you may need to try something else to reach that > instance. The specific use case that has come up is transfer. So if A is > talking to B, and B provided a GRUU to A, then if A wants to transfer C > to B, A can send a REFER to C with Refer-To being that GRUU. But if the > Contact wasn't a gruu, it may have to play various tricks people have > baked up, like using the AOR (possibly the To of the original INVITE > from A to B) along with caller preferences. > > > -Jonathan R. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 09:01:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDKzR-0002bU-6N; Wed, 16 Aug 2006 08:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDKzP-0002bP-CN for sip@ietf.org; Wed, 16 Aug 2006 08:59:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDKzN-0007fU-3A for sip@ietf.org; Wed, 16 Aug 2006 08:59:19 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Aug 2006 05:59:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,132,1154934000"; d="scan'208"; a="36479619:sNHT51465262" 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.20060308/8.12.11) with ESMTP id k7GCxGer027610; Wed, 16 Aug 2006 08:59:16 -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.12.10/8.12.6) with ESMTP id k7GCxDuK003221; Wed, 16 Aug 2006 08:59:16 -0400 (EDT) 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, 16 Aug 2006 08:59:14 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 08:59:13 -0400 Message-ID: <44E316A1.5000300@cisco.com> Date: Wed, 16 Aug 2006 08:59:13 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 References: <20060814021814.B719A222425@laser.networkresonance.com> <44E24269.7060604@cisco.com> <44E2A709.6030502@softarmor.com> In-Reply-To: <44E2A709.6030502@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2006 12:59:13.0815 (UTC) FILETIME=[C6208270:01C6C133] DKIM-Signature: a=rsa-sha1; q=dns; l=2124; t=1155733156; x=1156597156; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-ietf-sip-gruu-10 |To:Dean=20Willis=20; X=v=3Dcisco.com=3B=20h=3DIhYcytQwHYv3ZD0NF3ad3b/43PQ=3D; b=nH5kTOVnT8iashs0JLjvJuzj6H8Xd47Pzg+DVOAaPu9szJykhAMg7ryFuB7lmaWfNSJa7KaN XKBVXkmQbCbrTGhlT7ErS8XpWRapBWNH8XFe6znn07pyudMalN58UgWU; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > Paul Kyzivat wrote: >> Eric raised a lot of issues. I've been waiting to see Jonathan's >> response. Meanwhile I'll try to add my opinion about a couple of them. >> >> Paul >> >> Eric Rescorla wrote: >> >>> Why is it necessary to have GRUUs which are (1) identifiable >>> as GRUUs to peers but (2) can't be translated back to the AOR >>> by the peer? >> >> A use case might help here: >> >> - Bob has an "unlisted" AOR. >> - Alice calls Bob. (She knows the AOR.) >> - Alice does a transfer, >> transferring Charlie to Bob, replacing Alice:Bob call >> >> To do this, Alice sends a REFER to Charlie, with a Refer-To containing >> the contact URI from her dialog with Bob. >> >> Bob doesn't want Charlie to be able to learn his AOR as a result of >> this. If Bob uses a gruu obtained from the registrar for his AOR, he >> doesn't want Charlie to be able to reconstruct the AOR from it. > > But why does Charlie need to be able to tell that the URI he has for Bob > is a GRUU? I've been wondering about this since day one, and nobody > could ever tell me, so I just stopped asking hoping it would eventually > make sense. Of course, it could just be that I'm being overly dense but > I still wonder why we need this property. In this particular scenario, it isn't Charlie that needs to know the URI is a gruu - its Alice that needs to know. Alice is trying to figure out how to do the transfer: - if it is a gruu, then she will do the REFER with a Refer-To containing the gruu. - if it isn't marked as a gruu, she will have to conclude it might not be reachable by Alice, and have to try plan B. A likely thing to try is to use the To-URI from here dialog with Bob in the Refer-To. This has some chance of working, but also many ways in which it might fail. For instance: she might not be talking to Bob. When she called bob he might have been busy, and the call then might have been forwarded to Dave. But Bob may no longer be busy. In that case the referred call from Charlie won't reach Bob. Paul _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 09:11:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDL8p-0005ku-86; Wed, 16 Aug 2006 09:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDL8n-0005kk-4d for sip@ietf.org; Wed, 16 Aug 2006 09:09:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDL8l-0000mX-PE for sip@ietf.org; Wed, 16 Aug 2006 09:09:01 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Aug 2006 06:08:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,132,1154934000"; d="scan'208"; a="36481480:sNHT25199760" 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.20060308/8.12.11) with ESMTP id k7GD8ucW000356; Wed, 16 Aug 2006 09:08:56 -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.12.10/8.12.6) with ESMTP id k7GD8uuI005838; Wed, 16 Aug 2006 09:08:56 -0400 (EDT) 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); Wed, 16 Aug 2006 09:08:55 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 09:08:55 -0400 Message-ID: <44E318E7.1020309@cisco.com> Date: Wed, 16 Aug 2006 09:08:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 References: <6FC4416DDE56C44DA0AEE67BC7CA43710FED3732@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710FED3732@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2006 13:08:55.0835 (UTC) FILETIME=[2109B6B0:01C6C135] DKIM-Signature: a=rsa-sha1; q=dns; l=4099; t=1155733737; x=1156597737; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-ietf-sip-gruu-10 |To:Brian=20Stucker=20; X=v=3Dcisco.com=3B=20h=3DIhYcytQwHYv3ZD0NF3ad3b/43PQ=3D; b=Pb5DeFIr30vozFviLcaEcROgv4C4LeMWF0PsYK05sxLJP6Yh5XxlPo8lE4eF2Btb6hYEL/9F G965nU/Uso8GtWveVa3QSfsmTIhmT9OwJM+ZX1MWPJw6NARM+nTKMzgD; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Stucker wrote: > Hmm.. I beg to differ from the "local policy" argument about forwarding > services and GRUUs. > > If a GRUU is generally subject to the same type of routing as a non-GRUU > URI, then what's the point of having a GRUU? So you can guess as to what > the heck the proxy is going to do with it? Maybe it'll act like a > GRUU.... Maybe it won't... I would prefer not to leave it so vague. But I don't know what else we can do unless we go into the business of defining services. Its not that we want gruus to be treated the same as AORs. Its just that when you start to look at real services you discover that some of them are applicable to gruus and some are not. When we aren't defining the services, we must leave it to those who are to decide for each service whether it applies to gruus or not. The ones identified so far that seem applicable are the ones that perform authorization. It should still be possible to refuse a caller from reaching the target of the gruu. Paul > We already have a mechanism for SIP URIs that don't act like a GRUU, > they're called AORs. If someone wants their requests to route like an > AOR, then they should return an AOR, and not a GRUU. > > Regards, > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, August 15, 2006 4:54 PM >> To: Eric Rescorla >> Cc: sip@ietf.org >> Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 >> >> Eric raised a lot of issues. I've been waiting to see >> Jonathan's response. Meanwhile I'll try to add my opinion >> about a couple of them. >> >> Paul >> >> Eric Rescorla wrote: >> >>> Why is it necessary to have GRUUs which are (1) >> identifiable as GRUUs >>> to peers but (2) can't be translated back to the AOR by the peer? >> A use case might help here: >> >> - Bob has an "unlisted" AOR. >> - Alice calls Bob. (She knows the AOR.) >> - Alice does a transfer, >> transferring Charlie to Bob, replacing Alice:Bob call >> >> To do this, Alice sends a REFER to Charlie, with a Refer-To >> containing the contact URI from her dialog with Bob. >> >> Bob doesn't want Charlie to be able to learn his AOR as a >> result of this. If Bob uses a gruu obtained from the >> registrar for his AOR, he doesn't want Charlie to be able to >> reconstruct the AOR from it. >> >> Note that the peer (Alice) that first receives this gruu >> knows what AOR it is associated with, because she called it. >> This correlation is not available when the request gets to >> another peer - Charlie. >> >>> However, forwarding services, such as call forwarding, >> SHOULD NOT be >>> provided for requests sent to a GRUU. The intent of the >> GRUU is to >>> target a specific UA instance, and this is incompatible with >>> forwarding operations. >>> >>> This seems to me to get into policy. Are you saying that I >> can't have >>> my cell phone forward calls to some other phone just cause >> people call >>> my cell number rather than my generic "EKR" AOR? >> One intent of a gruu is to identify a specific UA instance. A >> service that ignores that intent will in general be counter >> productive. >> >> But this is a gray area, and so it is hard to state a precise >> yet general rule that can be used to decide whether a >> particular service should be applied to a request targeting a >> gruu. I think all the draft can do is sensitize developers to >> the issue, so that they think carefully about it regarding >> each service. >> >> The target UA itself can also decide to forward if it wants. >> But again it ought to take the intent into account. >> >> Thanks, >> Paul >> >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 16 11:53:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDNdf-0007BT-J6; Wed, 16 Aug 2006 11:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDNde-0007Am-7X for sip@ietf.org; Wed, 16 Aug 2006 11:49:02 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDNXT-0007my-B6 for sip@ietf.org; Wed, 16 Aug 2006 11:42:41 -0400 Received: from [131.161.248.82] (open-131-161-248-82.cliq.com [131.161.248.82]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k7GFgSF26970; Wed, 16 Aug 2006 08:42:28 -0700 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1351@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F1351@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5eb344b07237e72d815e46263b744088@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound - a new STUN keealive proposal Date: Wed, 16 Aug 2006 08:42:53 -0700 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Cullen Jennings , Rohan Mahy , SIP , ietf-behave@list.sipfoundry.org, Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, it is not that simple. Does the STUN client send retransmissions? What if the STUN transaction failed but other traffic to the same port succeeded before-hand? afterwards? What happens if the STUN transaction fails over an still open TCP connection? What if your TCP connection stalls? thanks, -rohan On Aug 15, 2006, at 23:55, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >>>>> 1. Editorial: Shouldn't the >>>>> stop-sending-STUN-requests-if-retransmissions-fail text (point >>>>> 2) be in 3849bis? To me it sounds like generic STUN >>>>> transaction procedures, which should be defined in the STUN >>>>> spec. Or, do we consider it specific to the STUN keepalive >>>>> usage for SIP??? >>>> >>>> Propose some text - as much as the advice can be made generic, I >>>> would want it to be in 3849bis. I suspect it hard to say too much >>>> more than what is in 3849. >>> >>> I need to think a little more about this a little bit more. >>> >>> Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, >>> and when a transaction shall be considered to have failed. But, >>> there > >>> is no text about what happens after that. THAT may be STUN usage >>> dependent, though, and in some cases it could even be "an >>> implementation issue"... >>> >>> But, I don't see anything SIP specific in saying that STUN keep-alive >>> re-transmissions shall stop if there is no reply, so shouldn't that >>> text be in 3849bis - either in the generic transaction chapter >>> (chapter 7), or in the keep-alive usage chapter (12.4)? The part of >>> the outbound spec defining the SIP usage of STUN keep-alive can then >>> of course refer to that text in 3849bis. >> >> It would be more appropriate in the keepalive usage section. >> >>> My main concern is that we dont specify things which people will >>> later > >>> find out belongs to another spec, and another WG. >> >> My concern is that if you stop doing STUN keepalives because you > haven't received a response in NNNN retransmissions, >> your NAT binding will time out soon thereafter. So here is some > proposed text for the RFC3489bis keepalive section: >> >> If, after retransmitting the STUN Binding Request NNNN times, >> the STUN client does not receive a STUN Binding Response, the >> STUN client should assume the STUN server is no longer >> available. The STUN client SHOULD cease retransmitting the >> STUN keepalives and inform other applications that the NAT >> binding is no longer valid (e.g., attempt to re-register if >> using SIP). > > I don't think we need to talk about NNNN times. Can't we simply say "If > the STUN client does not receive a response, and the STUN transaction > fails, the STUN client should assume....". > > Then, IF we want to talk about SIP actions taken due to the failure > (re-registers etc), THAT belongs to a SIP specific spec I think. > > Regards, > > Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 12:07:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDNtZ-0006Gd-6w; Wed, 16 Aug 2006 12:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDNtW-0006GN-Vd for sip@ietf.org; Wed, 16 Aug 2006 12:05:26 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDNtV-0001J4-LC for sip@ietf.org; Wed, 16 Aug 2006 12:05:26 -0400 Received: from [10.89.16.158] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7GG7el5022767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Aug 2006 11:07:40 -0500 Message-ID: <44E34242.1020701@softarmor.com> Date: Wed, 16 Aug 2006 11:05:22 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 References: <20060814021814.B719A222425@laser.networkresonance.com> <44E24269.7060604@cisco.com> <44E2A709.6030502@softarmor.com> <86y7tp6xmk.fsf@raman.networkresonance.com> <44E2C75C.6090300@cisco.com> In-Reply-To: <44E2C75C.6090300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF SIP List , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > I'll reply to Eric's comments individually asap, but one quick response > below: > > Eric Rescorla wrote: > >>> But why does Charlie need to be able to tell that the URI he has for >>> Bob is a GRUU? I've been wondering about this since day one, and >>> nobody could ever tell me, so I just stopped asking hoping it would >>> eventually make sense. Of course, it could just be that I'm being >>> overly dense but I still wonder why we need this property. >> >> >> This is the question I meant to be asking as well... > > The reason you need to be able to tell that the URI is a gruu, is that > if its not a gruu, you may need to try something else to reach that > instance. The specific use case that has come up is transfer. So if A is > talking to B, and B provided a GRUU to A, then if A wants to transfer C > to B, A can send a REFER to C with Refer-To being that GRUU. But if the > Contact wasn't a gruu, it may have to play various tricks people have > baked up, like using the AOR (possibly the To of the original INVITE > from A to B) along with caller preferences. You've got a URI. It might work, it might not. There are four possible cases, in order of (ideal world) probability. 1) The URI you have is Contact-specific and reachable because it is a GRUU (after all, GRUU is mandatory, right?) 2) The URI you have is Contact-specific and you can reach it because the system was properly designed and would have worked even without the GRUU hack. 3) The URI you have is reachable, but not contact-specific, so forking might mess you up (should have deprecated Forking). 4) The URI you have is not reachable. I believe you're expressing concern about the second two cases, and making the assumption that knowing that the URI you have is a GRUU means you will never encounter these cases. I'm not convinced that is true: for example, you might well be talking to a GRUU, but be precluded by network topology (or a broken firewall) or something from accessing that GRUU, even if you could have reached the native Contact: behind it. So in the end, you try using the URI (which might be a GRUU), and if that doesn't work and you're desperate, you try constructing alternate URIs from previous knowledge. Given this, I submit that there is NO DIFFERENCE IN BEHAVIOR driven by knowledge that the target URI claims to have the GRUU properties. -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 17:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDSko-0000Pq-BP; Wed, 16 Aug 2006 17:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDSkm-0000Pg-Er for sip@ietf.org; Wed, 16 Aug 2006 17:16:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDFtd-0002cY-Kw for sip@ietf.org; Wed, 16 Aug 2006 03:33:01 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDFi2-0004Ms-4Y for sip@ietf.org; Wed, 16 Aug 2006 03:21:08 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Aug 2006 00:21:01 -0700 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.20060308/8.12.11) with ESMTP id k7G7L1T4024717; Wed, 16 Aug 2006 00:21:01 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7G7L0QV023613; Wed, 16 Aug 2006 00:21:00 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 00:21:00 -0700 Received: from [172.17.155.169] ([10.21.120.90]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 00:21:00 -0700 Message-ID: <44E2C75C.6090300@cisco.com> Date: Wed, 16 Aug 2006 03:21:00 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EKR Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 References: <20060814021814.B719A222425@laser.networkresonance.com> <44E24269.7060604@cisco.com> <44E2A709.6030502@softarmor.com> <86y7tp6xmk.fsf@raman.networkresonance.com> In-Reply-To: <86y7tp6xmk.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2006 07:21:00.0261 (UTC) FILETIME=[8639E950:01C6C104] DKIM-Signature: a=rsa-sha1; q=dns; l=1410; t=1155712861; x=1156576861; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-ietf-sip-gruu-10; X=v=3Dcisco.com=3B=20h=3Dh95hqDNVfxvu6y5EFwdmf6h4SGw=3D; b=ebqQhiyesrh3ETyAehgugt2LYo2QUZZIZuiEK9t+v7Fqp2ocmUfbvrRVJ6VO7p/4sV2+Ru0N +CFjFqk057ErYnwJH/z4JcNGAvZreZxFYy9SsWG+Ewg9MIKAnc8lm4A5; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List , Paul Kyzivat , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'll reply to Eric's comments individually asap, but one quick response below: Eric Rescorla wrote: >>But why does Charlie need to be able to tell that the URI he has for >>Bob is a GRUU? I've been wondering about this since day one, and >>nobody could ever tell me, so I just stopped asking hoping it would >>eventually make sense. Of course, it could just be that I'm being >>overly dense but I still wonder why we need this property. > > > This is the question I meant to be asking as well... The reason you need to be able to tell that the URI is a gruu, is that if its not a gruu, you may need to try something else to reach that instance. The specific use case that has come up is transfer. So if A is talking to B, and B provided a GRUU to A, then if A wants to transfer C to B, A can send a REFER to C with Refer-To being that GRUU. But if the Contact wasn't a gruu, it may have to play various tricks people have baked up, like using the AOR (possibly the To of the original INVITE from A to B) along with caller preferences. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 16 21:06:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDWID-0003Vm-7I; Wed, 16 Aug 2006 21:03:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDWIB-0003Ux-RX for sip@ietf.org; Wed, 16 Aug 2006 21:03:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDQkO-0001kG-Eq for sip@ietf.org; Wed, 16 Aug 2006 15:08:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDQWG-0002Yl-Fr for sip@ietf.org; Wed, 16 Aug 2006 14:53:38 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Aug 2006 11:53:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,133,1154934000"; d="scan'208"; a="36550793:sNHT24193036" 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.20060308/8.12.11) with ESMTP id k7GIrZFS027717; Wed, 16 Aug 2006 14:53:35 -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.12.10/8.12.6) with ESMTP id k7GIrYuI013307; Wed, 16 Aug 2006 14:53:34 -0400 (EDT) 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); Wed, 16 Aug 2006 14:53:35 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 14:53:34 -0400 Message-ID: <44E369AD.2010105@cisco.com> Date: Wed, 16 Aug 2006 14:53:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 References: <20060814021814.B719A222425@laser.networkresonance.com> <44E24269.7060604@cisco.com> <44E2A709.6030502@softarmor.com> <86y7tp6xmk.fsf@raman.networkresonance.com> <44E2C75C.6090300@cisco.com> <44E34242.1020701@softarmor.com> In-Reply-To: <44E34242.1020701@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2006 18:53:34.0507 (UTC) FILETIME=[467CA7B0:01C6C165] DKIM-Signature: a=rsa-sha1; q=dns; l=3401; t=1155754415; x=1156618415; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-ietf-sip-gruu-10 |To:Dean=20Willis=20; X=v=3Dcisco.com=3B=20h=3DIhYcytQwHYv3ZD0NF3ad3b/43PQ=3D; b=s0ku8+ATv9PT6EzJ5U87HG7nJU99IqzBlI+0VRmQYFw8hMNQ9351sFDMqTTpPJkmTvUAk5uu JzaejJXl7BBrWln3MsORLyomaTQefYUynsdwXKsell5vhFbXLnYo/B1v; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.4 (--) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > Jonathan Rosenberg wrote: >> I'll reply to Eric's comments individually asap, but one quick >> response below: >> >> Eric Rescorla wrote: >> >>>> But why does Charlie need to be able to tell that the URI he has for >>>> Bob is a GRUU? I've been wondering about this since day one, and >>>> nobody could ever tell me, so I just stopped asking hoping it would >>>> eventually make sense. Of course, it could just be that I'm being >>>> overly dense but I still wonder why we need this property. >>> >>> >>> This is the question I meant to be asking as well... >> >> The reason you need to be able to tell that the URI is a gruu, is that >> if its not a gruu, you may need to try something else to reach that >> instance. The specific use case that has come up is transfer. So if A >> is talking to B, and B provided a GRUU to A, then if A wants to >> transfer C to B, A can send a REFER to C with Refer-To being that >> GRUU. But if the Contact wasn't a gruu, it may have to play various >> tricks people have baked up, like using the AOR (possibly the To of >> the original INVITE from A to B) along with caller preferences. > > You've got a URI. It might work, it might not. > > There are four possible cases, in order of (ideal world) probability. > > 1) The URI you have is Contact-specific and reachable because it is a > GRUU (after all, GRUU is mandatory, right?) > > 2) The URI you have is Contact-specific and you can reach it because the > system was properly designed and would have worked even without the GRUU > hack. > > 3) The URI you have is reachable, but not contact-specific, so forking > might mess you up (should have deprecated Forking). > > 4) The URI you have is not reachable. > > I believe you're expressing concern about the second two cases, and > making the assumption that knowing that the URI you have is a GRUU means > you will never encounter these cases. I'm not convinced that is true: > for example, you might well be talking to a GRUU, but be precluded by > network topology (or a broken firewall) or something from accessing that > GRUU, even if you could have reached the native Contact: behind it. > > So in the end, you try using the URI (which might be a GRUU), and if > that doesn't work and you're desperate, you try constructing alternate > URIs from previous knowledge. Given this, I submit that there is NO > DIFFERENCE IN BEHAVIOR driven by knowledge that the target URI claims to > have the GRUU properties. Dean, At the moment, the default assumption is that the contact isn't usable. And that is a pretty good assumption. I doubt many would want to change the default assumption, which would result in two tries in most cases today. Plus, the particular kinds of failures that one might want to retry aren't very obvious, and include some that take a long time to fail. Nor is it acceptable to try the AOR and then try the Contact if the AOR fails. That can lead to all sorts of strange and time consuming things happening before you find out about it. In a lot of cases (e.g. when there is a Replaces header) it should eventually fail, but the user experience is likely to suck. And there may be services where there won't be any Replaces header - where the new call succeeds but reaches the wrong target. Paul _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 17 08:19:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDgmj-000149-IQ; Thu, 17 Aug 2006 08:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDgmh-00013y-BU for sip@ietf.org; Thu, 17 Aug 2006 08:15:39 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDgmX-0005AV-Mg for sip@ietf.org; Thu, 17 Aug 2006 08:15:39 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 85E044F006C; Thu, 17 Aug 2006 14:15:12 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 14:15:11 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 14:15:11 +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 Subject: RE: [Sip] Outbound - a new STUN keealive proposal Date: Thu, 17 Aug 2006 14:15:10 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F136E@esealmw113.eemea.ericsson.se> In-Reply-To: <5eb344b07237e72d815e46263b744088@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound - a new STUN keealive proposal Thread-Index: AcbBSqF3iYuYERbJQ720o18RUkyuxQAAp4yA From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 17 Aug 2006 12:15:11.0431 (UTC) FILETIME=[C98E7570:01C6C1F6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Cullen Jennings , SIP , ietf-behave@list.sipfoundry.org, Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >Christer, it is not that simple. Does the STUN client send retransmissions?=20 According to 3849bis, it does. >What if the STUN transaction failed but other traffic to the same port succeeded before-hand? afterwards? That is an interesting question. But, I don't tink it's SIP specific, because that "other traffic" could be non-SIP. But, I am not sure we want to specify behavior, saying that one protocol behavior is dependent on another... >What happens if the STUN transaction fails over an still open TCP connection? What if your TCP connection stalls? That is also an interesting question. But, I don't think that is SIP specific either. So, there may be more issues we need to consider. But, if we can agree they belong to 3849bis we can move the discussion to BEHAVE, and it won't affect the work on the outbound spec. But, again, if we want the STUN failure to trigger SIP specific actions (e.g. trigger the sending of a new REGISTER), that should of course be described in the outbound draft. Regards, Christer On Aug 15, 2006, at 23:55, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >>>>> 1. Editorial: Shouldn't the >>>>> stop-sending-STUN-requests-if-retransmissions-fail text (point >>>>> 2) be in 3849bis? To me it sounds like generic STUN >>>>> transaction procedures, which should be defined in the STUN >>>>> spec. Or, do we consider it specific to the STUN keepalive >>>>> usage for SIP??? >>>> >>>> Propose some text - as much as the advice can be made generic, I=20 >>>> would want it to be in 3849bis. I suspect it hard to say too much=20 >>>> more than what is in 3849. >>> >>> I need to think a little more about this a little bit more. >>> >>> Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, >>> and when a transaction shall be considered to have failed. But,=20 >>> there > >>> is no text about what happens after that. THAT may be STUN usage=20 >>> dependent, though, and in some cases it could even be "an=20 >>> implementation issue"... >>> >>> But, I don't see anything SIP specific in saying that STUN=20 >>> keep-alive re-transmissions shall stop if there is no reply, so=20 >>> shouldn't that text be in 3849bis - either in the generic=20 >>> transaction chapter (chapter 7), or in the keep-alive usage chapter=20 >>> (12.4)? The part of the outbound spec defining the SIP usage of STUN >>> keep-alive can then of course refer to that text in 3849bis. >> >> It would be more appropriate in the keepalive usage section. >> >>> My main concern is that we dont specify things which people will=20 >>> later > >>> find out belongs to another spec, and another WG. >> >> My concern is that if you stop doing STUN keepalives because you > haven't received a response in NNNN retransmissions, >> your NAT binding will time out soon thereafter. So here is some > proposed text for the RFC3489bis keepalive section: >> >> If, after retransmitting the STUN Binding Request NNNN times, the=20 >> STUN client does not receive a STUN Binding Response, the STUN=20 >> client should assume the STUN server is no longer available. The=20 >> STUN client SHOULD cease retransmitting the STUN keepalives and=20 >> inform other applications that the NAT binding is no longer valid=20 >> (e.g., attempt to re-register if using SIP). > > I don't think we need to talk about NNNN times. Can't we simply say=20 > "If the STUN client does not receive a response, and the STUN=20 > transaction fails, the STUN client should assume....". > > Then, IF we want to talk about SIP actions taken due to the failure=20 > (re-registers etc), THAT belongs to a SIP specific spec I think. > > Regards, > > Christer _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 17 23:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDvBY-0007Xz-Dl; Thu, 17 Aug 2006 23:38:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDvBW-0007Xq-Re for sip@ietf.org; Thu, 17 Aug 2006 23:38:14 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDvBV-0000jh-Go for sip@ietf.org; Thu, 17 Aug 2006 23:38:14 -0400 Received: from [192.168.2.106] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7I3eTgl030475 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 17 Aug 2006 22:40:30 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip List From: Dean Willis Date: Thu, 17 Aug 2006 22:37:55 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Sip] Charter revisions approved, get ready to WGLC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have it on good authority that our charter has been officially revised to embrace the following milestones: Aug 2006 Submit Answering/Alerting Modes to the IESG (PS) Aug 2006 Mechanism and guidelines for outbound connections to WGLC (PS) Aug 2006 Mechanism for connected identity to WGLC (PS) Aug 2006 Diagnostic Responses for SIP Errors to WGLC (PS) Aug 2006 Consent-Based Communications WGLC (PS) Sep 2006 Mechanism for obtaining globally routable unique URIs (GRUU) to IESG (PS) Sep 2006 Mechanism and guidelines for outbound connections to IESG (PS) Sep 2006 Location Conveyance with SIP to WGLC (PS) Sep 2006 Certificate Management Service for SIP to WGLC (PS) Sep 2006 Rejecting Anonymous Requests to WGLC (PS) Sep 2006 Session Policies to WGLC as PS Sep 2006 Example security flows to WGLC (Informational) Oct 2006 Consent-Based Communications to IESG (PS) Oct 2006 Diagnostic Responses for SIP Errors to IESG (PS) Oct 2006 Rejecting Anonymous Requests to IESG (PS) Oct 2006 Mechanism for connected identity to IESG (PS) Oct 2006 Addressing an Amplification Vulnerability in Forking Proxies to IESG (PS) Oct 2006 Extensions to SIP UA Profile Delivery Change Notification Event Package for XCAP to WGLC (PS) Oct 2006 Refering to Multiple Resources to IESG as PS Nov 2006 Certificate Management Service for SIP to IESG (PS) Nov 2006 Session Policies to IESG as PS Dec 2006 Extensions to SIP UA Profile Delivery Change Notification Event Package for XCAP to IESG (PS) Dec 2006 Location Conveyance with SIP to IESG (PS) Dec 2006 Example security flows to IESG (Informational) Dec 2006 Roadmap for SIP to WGLC (Informational) Mar 2007 Roadmap for SIP to IESG (Informational) Mar 2007 Guidelines for use of SIP security to WGLC (Informational) Apr 2007 Connection reuse mechanism to IESG (PS) Jun 2007 Guidelines for use of SIP security to IESG (Informational) Jun 2007 Identify requirements for test matrix to move SIP to Draft Standard Jun 2007 Revise charter Sep 2007 Using SAML for SIP to WGLC (PS) Dec 2007 Using SAML for SIP to IESG (PS) So if I'm reading this right, we have about 1 week to start WGLC on: Aug 2006 Mechanism and guidelines for outbound connections to WGLC (PS) Aug 2006 Mechanism for connected identity to WGLC (PS) Aug 2006 Diagnostic Responses for SIP Errors to WGLC (PS) Aug 2006 Consent-Based Communications WGLC (PS) -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 18 08:17:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE3EP-0002wv-N4; Fri, 18 Aug 2006 08:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE3EN-0002wq-O7 for sip@ietf.org; Fri, 18 Aug 2006 08:13:43 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE3EM-0002XS-RP for sip@ietf.org; Fri, 18 Aug 2006 08:13:43 -0400 Received: (qmail 11532 invoked by uid 0); 18 Aug 2006 12:13:16 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Aug 2006 12:13:16 -0000 Message-ID: <002501c6c2bf$b27df8a0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Fri, 18 Aug 2006 14:13:20 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Cc: Subject: [Sip] review of draft-ietf-sip-gruu-10.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0004290556==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0004290556== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C6C2D0.75AE9680" This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C6C2D0.75AE9680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here are my review comments for draft-ietf-sip-gruu-10.txt (all nits): section 2:=20 - "contact: ... bound to an AOR or GRUU" =3D> "... bound to an AOR and = GRUU" - "contact: ... the value of the Contact header field" =3D> "a value" or = "a Contact header field" - "remote target: ... updated by target refresh requests" =3D> add "or = responses" - "Contact header field: ... Depending on the semantics": isn't it = simpler to say that in REGISTER requests and responses a Contact = contains a contact, and in all other requests and responses it contains = a remote target? section 3: "The AOR property: ... REGISTER request." =3D> "REGISTER requests" (add = 's') "The alias property: ...is identical to another URI" =3D> "is identical = to the treatment of another URI" (is "treatment" well defined here?) "anonymous property": perhaps better called the "anonymity property"? The flow of this section is somewhat confusing: It first talks about = properties a URI might have, then about three more properties that = combine to form the GRUU property, and then adds a remark referring to = "these properties" (page 5). Suggestion to have 1 list of all = properties, then define the new property 'GRUU' which this specification = adds section 4.2 Conferencing: "The URI in the Contact header field also has a callee capabilities [8] = parameter which indicates that this URI is a conference URI." I assume = this is referring to the "sip.isfocus" media feature tag, which = "...indicates that the UA is a conference server" [12]. It is not a URI = parameter but a header parameter section 5: "...will contain the "gruu" parameter in each Contact header field" =3D> = "will contain the "gruu" parameter in each corresponding Contact header = field" When the user has multiple registered UAs and some of those don't = support GRUU, the REGISTER response would contain their Contacts without = 'gruu' parameter "RFC 3261 mandates that the Contact header field have the GRUU property, = and this specification provides a reliable way for a UA to obtain one." = =3D> "...to fulfill that requirement" (UA obtaining a GRUU property = makes no sense) "...for a UA receiving the message to know whether the remote target is = a GRUU or not.This can be known to a remote target through the presence = of the "gruu" URI parameter." =3D> " ..or not. It can learn this from = the presence of the "gruu" URI parameter" "...when that proxy receives a request sent to the GRUU, it can = determine that the request is a GRUU by the presence of the "gruu" = parameter" : although this section si not normative, I believe we said = that a proxy should not depend only on the 'gruu' flag for this. Suggest = to omit "by the presence of the 'gruu' parameter" here "However, when the server maps the GRUU to the contact bound to it, the = server will copy ..." =3D> replace "the server"(2x) by "a proxy" and = "it" section 6: "...the GRUU MUST exhibit the following properties:": add " The URI MUST = NOT include the "grid" parameter" as a new bullet section 7.1.1.1: "...it is RECOMMENDED that a UA instance provide a different contact URI = for each AOR": Do we need to specify how this should be done? = Implementors might be tempted to use the 'grid' URI parameter for this, = but that is not going to work. Distinct username parts would seem best?=20 Actually, on second thought: is this really needed? a UAS can = distinguish requests sent to different AORs by the URI in the To header; = using that it can determine the right GRUU to use (ie typically it would = maintain a mapping AoR domain -> GRUU ) "Specifically, if a contact contains an instance ID" -> capitalize = "Contact" "If a client does include a contact which contains a GRUU" -> idem - Perhaps should also say that UA MUST NOT use "gruu" as a value in = Proxy-Require (for completeness) - can I get a GRUU for non-SIP Contacts? (e.g. "mailto:") section 8.1.1: - list of dialog-forming and target refresh requests and responses is = incomplete. Should add "1xx responses to dialog-forming requests having = a to-tag, UPDATE request + 2xx response" - when a UA uses a GRUU e.g. in a PIDF document, can it convert 'sip' to = 'sips' to have the other side use TLS until the proxy? section 8.1.3:=20 For out-of-dialog requests sent to a GRUU, the To header will contain = the GRUU, including the 'grid' parameter (except for broken UACs that = strip it).=20 It seems that for GRUU purposes we could do without proxy copying of = 'grid' and just rely on To? (though a URI parameter that survives = rewriting can be useful for other applications, of course, for example = between proxies) section 8.2.1: (Request Targeting for Requests Outside of a Dialog) "These requests are identified by their lack of a Route header field = when received by the proxy": out-of-dialog requests could contain a = Route header. It should say something like "request does not contain a = Route header that the proxy recognises as one it inserted into a = Record-Route header" section 9 at the end: elements also need to strip any 'grid' URI = parameter, if present, to obtain the AOR Regards, jeroen ------=_NextPart_000_0022_01C6C2D0.75AE9680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Here are my review comments for=20 draft-ietf-sip-gruu-10.txt (all nits):
 
section 2:
- "contact: ... bound to an AOR or = GRUU" =3D> "...=20 bound to an AOR and GRUU"
- "contact: ... the value of the = Contact header=20 field" =3D> "a value" or "a Contact header field"
- "remote target: ... updated by target = refresh=20 requests" =3D> add "or responses"
- "Contact header field: ... Depending = on the=20 semantics": isn't it simpler to say that in REGISTER requests and = responses a=20 Contact contains a contact, and in all other requests and responses it = contains=20 a remote target?
 
section 3:
"The AOR property: ... REGISTER = request." =3D>=20 "REGISTER requests" (add 's')
"The alias property: ...is identical to = another=20 URI" =3D> "is identical to the treatment of another URI" (is = "treatment" well=20 defined here?)
"anonymous property": perhaps better = called the=20 "anonymity property"?
 
The flow of this section is somewhat = confusing: It=20 first talks about properties a URI might have, then about three more = properties=20 that combine to form the GRUU property, and then adds a remark referring = to=20 "these properties" (page 5). Suggestion to have 1 list of all = properties, then=20 define the new property 'GRUU' which this specification = adds
 
section 4.2 Conferencing:
"The URI in the Contact header field = also has a=20 callee capabilities [8] parameter which indicates that this URI is a = conference=20 URI." I assume this is referring to the "sip.isfocus" media feature tag, = which=20 "...indicates that the UA is a conference server" [12]. It is not a URI=20 parameter but a header parameter
 
section 5:
"...will contain the "gruu" parameter = in each=20 Contact header field" =3D> "will contain the "gruu" parameter in each = corresponding Contact header field"
When the user has multiple registered = UAs and some=20 of those don't support GRUU, the REGISTER response would contain their = Contacts=20 without 'gruu' parameter
 
"RFC 3261 mandates that the Contact = header field=20 have the GRUU property, and this specification provides a reliable way = for a UA=20 to obtain one." =3D> "...to fulfill that requirement" (UA obtaining a = GRUU=20 property makes no sense)
 
"...for a UA receiving the message to = know whether=20 the remote target is a GRUU or not.This can be known to a remote target = through=20 the presence of the "gruu" URI parameter." =3D> " ..or not. It can = learn this=20 from the presence of the "gruu" URI parameter"
 
"...when that proxy receives a request = sent to the=20 GRUU, it can determine that the request is a GRUU by the presence of the = "gruu"=20 parameter" : although this section si not normative, I believe we said = that a=20 proxy should not depend only on the 'gruu' flag for this. Suggest to = omit "by=20 the presence of the 'gruu' parameter" here
 
"However, when the server maps the GRUU = to the=20 contact bound to it, the server will copy ..." =3D> replace "the = server"(2x) by=20 "a proxy" and "it"
 
section 6:
"...the GRUU MUST exhibit the following = properties:": add " The URI MUST NOT include the "grid" parameter" as a = new=20 bullet
 
section 7.1.1.1:
 
"...it is RECOMMENDED that a UA = instance provide a=20 different contact URI for each AOR": Do we need to specify how this = should be=20 done? Implementors might be tempted to use the 'grid' URI parameter for = this,=20 but that is not going to work. Distinct username parts would seem best?=20
Actually, on second thought: is this = really needed?=20 a UAS can distinguish requests sent to different AORs by the URI in the = To=20 header; using that it can determine the right GRUU to use (ie typically = it would=20 maintain a mapping AoR domain -> GRUU )
 
"Specifically, if a contact contains an = instance=20 ID" -> capitalize "Contact"
"If a client does include a contact = which contains=20 a GRUU" -> idem
 
- Perhaps should also say that UA MUST = NOT use=20 "gruu" as a value in Proxy-Require (for completeness)
- can I get a GRUU for non-SIP = Contacts? (e.g.=20 "mailto:")
 
section 8.1.1:
- list of dialog-forming and target = refresh=20 requests and responses is incomplete. Should add "1xx responses to=20 dialog-forming requests having a to-tag, UPDATE request + 2xx=20 response"
 
- when a UA uses a GRUU e.g. in a PIDF = document,=20 can it convert 'sip' to 'sips' to have the other side use TLS until the=20 proxy?
 
section 8.1.3:
For out-of-dialog requests sent to a = GRUU, the To=20 header will contain the GRUU, including the 'grid' parameter (except for = broken=20 UACs that strip it).
It seems that for GRUU purposes we = could do without=20 proxy copying of 'grid' and just rely on To? (though a URI parameter = that=20 survives rewriting can be useful for other applications, of course, for = example=20 between proxies)
 
section 8.2.1: (Request Targeting for = Requests=20 Outside of a Dialog)
"These requests are identified by their = lack of a=20 Route header field when received by the proxy": out-of-dialog requests = could=20 contain a Route header. It should say something like "request does not = contain a=20 Route header that the proxy recognises as one it inserted into a = Record-Route=20 header"
 
section 9 at the end: elements also = need to strip=20 any 'grid' URI parameter, if present, to obtain the AOR
 
Regards,
 
jeroen
 
 
 
 
 
 
 
------=_NextPart_000_0022_01C6C2D0.75AE9680-- --===============0004290556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============0004290556==-- From sip-bounces@ietf.org Fri Aug 18 12:32:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE7BK-0005Ht-TP; Fri, 18 Aug 2006 12:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDAQv-0007tN-Ep for sip@ietf.org; Tue, 15 Aug 2006 21:43:01 -0400 Received: from web38908.mail.mud.yahoo.com ([209.191.125.114]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDAGh-0000wc-Rb for sip@ietf.org; Tue, 15 Aug 2006 21:32:31 -0400 Received: (qmail 54857 invoked by uid 60001); 16 Aug 2006 01:32:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=B/PBtuTz8gf4ZN+0UyRE3uP261aNDoa6nY1vSuTOqe/abGNfSVaZR02pZJj0HEFo0LfoekiVqnvmQJW3mdGDsWY1YeQqUx2Tt3YUZM5C7Nbcs8Ic+GHOiuUOu97xgWSc+pXLWl8IYiruYXwX+jwOlehTdTrYTb8yaI1/DAaB6wA= ; Message-ID: <20060816013227.54855.qmail@web38908.mail.mud.yahoo.com> Received: from [68.38.24.167] by web38908.mail.mud.yahoo.com via HTTP; Tue, 15 Aug 2006 18:32:27 PDT Date: Tue, 15 Aug 2006 18:32:27 -0700 (PDT) From: youngsun song Subject: RE: [Sip] The Problem with PRACK To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Fri, 18 Aug 2006 12:26:49 -0400 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0597828635==" Errors-To: sip-bounces@ietf.org --===============0597828635== Content-Type: multipart/alternative; boundary="0-86939268-1155691947=:50193" Content-Transfer-Encoding: 8bit --0-86939268-1155691947=:50193 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, I recall much discussion on PRACK earlier this year, regarding whether to limit its usage to containing just answer not offer, as well as other changes to it. Has there been any consensus? Thanks, YoungSun --------------------------------- Get your email and more, right on the new Yahoo.com --0-86939268-1155691947=:50193 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello,
 
I recall much discussion on PRACK earlier this year, regarding whether to limit its usage to containing just answer not offer, as well as other changes to it.
 
Has there been any consensus?
 
Thanks,
YoungSun

Get your email and more, right on the new Yahoo.com --0-86939268-1155691947=:50193-- --===============0597828635== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============0597828635==-- From sip-bounces@ietf.org Fri Aug 18 18:04:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GECPF-0003Ts-Ez; Fri, 18 Aug 2006 18:01:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GECPE-0003Tf-3R for sip@ietf.org; Fri, 18 Aug 2006 18:01:32 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GECPC-0007Om-KL for sip@ietf.org; Fri, 18 Aug 2006 18:01:32 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7IM19R01758; Fri, 18 Aug 2006 18:01:10 -0400 (EDT) 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 Subject: RE: [Sip] Comments on draft-ietf-sip-gruu-10 Date: Fri, 18 Aug 2006 17:01:08 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710FFFEB28@zrc2hxm2.corp.nortel.com> In-Reply-To: <44E318E7.1020309@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-ietf-sip-gruu-10 Thread-Index: AcbBNSrKVisZh74NTt2A5J+bzHG39wAD5W4g From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't view it as being in the business of defining services, but the business of defining interoperability. I believe that is in scope of the IETF. What I'm concerned about is that a proxy is going to take license with the operation of the protocol. If there's a legitimate case for having a GRUU route to an alternate destination (which I think there likely is, ie. voicemail) and there needs to be a way of preventing that so an application can tell the proxy that it should strictly route to the GRUU address and nowhere else (which I think there likely is a need) then we should specify the mechanism by which this can be done, and not the application. It would be a shame to wind up with "loose-routing" GRUUs after the fact. Regards, Brian =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, August 16, 2006 8:09 AM > To: Stucker, Brian (RICH1:B620) > Cc: Eric Rescorla; sip@ietf.org > Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 >=20 >=20 >=20 > Brian Stucker wrote: > > Hmm.. I beg to differ from the "local policy" argument about=20 > > forwarding services and GRUUs. > >=20 > > If a GRUU is generally subject to the same type of routing as a=20 > > non-GRUU URI, then what's the point of having a GRUU? So=20 > you can guess=20 > > as to what the heck the proxy is going to do with it? Maybe=20 > it'll act=20 > > like a GRUU.... Maybe it won't... >=20 > I would prefer not to leave it so vague. But I don't know=20 > what else we can do unless we go into the business of=20 > defining services. >=20 > Its not that we want gruus to be treated the same as AORs.=20 > Its just that when you start to look at real services you=20 > discover that some of them are applicable to gruus and some=20 > are not. When we aren't defining the services, we must leave=20 > it to those who are to decide for each service whether it=20 > applies to gruus or not. >=20 > The ones identified so far that seem applicable are the ones=20 > that perform authorization. It should still be possible to=20 > refuse a caller from reaching the target of the gruu. >=20 > Paul >=20 > > We already have a mechanism for SIP URIs that don't act=20 > like a GRUU,=20 > > they're called AORs. If someone wants their requests to=20 > route like an=20 > > AOR, then they should return an AOR, and not a GRUU. > >=20 > > Regards, > > Brian > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Tuesday, August 15, 2006 4:54 PM > >> To: Eric Rescorla > >> Cc: sip@ietf.org > >> Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 > >> > >> Eric raised a lot of issues. I've been waiting to see Jonathan's=20 > >> response. Meanwhile I'll try to add my opinion about a couple of=20 > >> them. > >> > >> Paul > >> > >> Eric Rescorla wrote: > >> > >>> Why is it necessary to have GRUUs which are (1) > >> identifiable as GRUUs > >>> to peers but (2) can't be translated back to the AOR by the peer? > >> A use case might help here: > >> > >> - Bob has an "unlisted" AOR. > >> - Alice calls Bob. (She knows the AOR.) > >> - Alice does a transfer, > >> transferring Charlie to Bob, replacing Alice:Bob call > >> > >> To do this, Alice sends a REFER to Charlie, with a Refer-To=20 > >> containing the contact URI from her dialog with Bob. > >> > >> Bob doesn't want Charlie to be able to learn his AOR as a=20 > result of=20 > >> this. If Bob uses a gruu obtained from the registrar for=20 > his AOR, he=20 > >> doesn't want Charlie to be able to reconstruct the AOR from it. > >> > >> Note that the peer (Alice) that first receives this gruu=20 > knows what=20 > >> AOR it is associated with, because she called it. > >> This correlation is not available when the request gets to another=20 > >> peer - Charlie. > >> > >>> However, forwarding services, such as call forwarding, > >> SHOULD NOT be > >>> provided for requests sent to a GRUU. The intent of the > >> GRUU is to > >>> target a specific UA instance, and this is incompatible with > >>> forwarding operations. > >>> > >>> This seems to me to get into policy. Are you saying that I > >> can't have > >>> my cell phone forward calls to some other phone just cause > >> people call > >>> my cell number rather than my generic "EKR" AOR? > >> One intent of a gruu is to identify a specific UA=20 > instance. A service=20 > >> that ignores that intent will in general be counter productive. > >> > >> But this is a gray area, and so it is hard to state a precise yet=20 > >> general rule that can be used to decide whether a=20 > particular service=20 > >> should be applied to a request targeting a gruu. I think all the=20 > >> draft can do is sensitize developers to the issue, so that=20 > they think=20 > >> carefully about it regarding each service. > >> > >> The target UA itself can also decide to forward if it wants.=20 > >> But again it ought to take the intent into account. > >> > >> Thanks, > >> Paul > >> > >> _______________________________________________ > >> Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 18 18:55:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEDCV-0001US-55; Fri, 18 Aug 2006 18:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEDCS-0001Ba-SF for sip@ietf.org; Fri, 18 Aug 2006 18:52:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEAia-0002VR-6R for sip@ietf.org; Fri, 18 Aug 2006 16:13:24 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GEAQg-0003nI-IC for sip@ietf.org; Fri, 18 Aug 2006 15:55:03 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 869BC8E0001; Fri, 18 Aug 2006 21:54:47 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 21:54:47 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 21:54:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] The Problem with PRACK Date: Fri, 18 Aug 2006 21:54:46 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1388@esealmw113.eemea.ericsson.se> In-Reply-To: <20060816013227.54855.qmail@web38908.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The Problem with PRACK Thread-Index: AcbC5CnPsmojDpOeT52RoErulfTvoAAG8wXA From: "Christer Holmberg \(JO/LMF\)" To: "youngsun song" , X-OriginalArrivalTime: 18 Aug 2006 19:54:46.0991 (UTC) FILETIME=[2848BDF0:01C6C300] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1427444632==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1427444632== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C300.27F006C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C300.27F006C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I think there is consensus that there are issues which need to be investigated, and those issues will be documented in the offer/answer draft. =20 No decissions with regards to changing the rules for PRACK etc have been done, though. =20 Regards, =20 Christer ________________________________ From: youngsun song [mailto:yss914@yahoo.com]=20 Sent: 16. elokuuta 2006 4:32 To: sip@ietf.org Subject: RE: [Sip] The Problem with PRACK Hello, =20 I recall much discussion on PRACK earlier this year, regarding whether to limit its usage to containing just answer not offer, as well as other changes to it. =20 Has there been any consensus? =20 Thanks, YoungSun ________________________________ Get your email and more, right on the new Yahoo.com =20 ------_=_NextPart_001_01C6C300.27F006C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I=20 think there is consensus that there are issues which need to be = investigated,=20 and those issues will be documented in the offer/answer=20 draft.
 
No=20 decissions with regards to changing the rules for PRACK etc have been = done,=20 though.
 
Regards,
 
Christer

From: youngsun song = [mailto:yss914@yahoo.com]=20
Sent: 16. elokuuta 2006 4:32
To:=20 sip@ietf.org
Subject: RE: [Sip] The Problem with=20 PRACK

Hello,
 
I recall much discussion on PRACK earlier this year, regarding = whether to=20 limit its usage to containing just answer not offer, as well as other = changes to=20 it.
 
Has there been any consensus?
 
Thanks,
YoungSun

Get your email and more, right on the new=20 Yahoo.com ------_=_NextPart_001_01C6C300.27F006C0-- --===============1427444632== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============1427444632==-- From sip-bounces@ietf.org Sun Aug 20 14:40:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEs8y-0001gX-7q; Sun, 20 Aug 2006 14:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEs8x-0001gS-9r for sip@ietf.org; Sun, 20 Aug 2006 14:35:31 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEs8t-00067p-2F for sip@ietf.org; Sun, 20 Aug 2006 14:35:31 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <20060820183524012002igame>; Sun, 20 Aug 2006 18:35:24 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k7KIZNWI001725 for ; Sun, 20 Aug 2006 14:35:24 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k7KIZN5M001721; Sun, 20 Aug 2006 14:35:23 -0400 Date: Sun, 20 Aug 2006 14:35:23 -0400 Message-Id: <200608201835.k7KIZN5M001721@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: (xavier.marjou@orange-ft.com) Subject: Re: [Sip] GRUU and Mid-Dialog Requests References: X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Xavier Marjou" The point is that additional processing is needed by the current draft in home proxies. To remove this (not-needed?) burden, one could imagine other ways to advertise the GRUU (e.g. a Contact-Gruu header field) instead of advertising it in the Contact header field (e.g. in a 200 of INVITE). The remote user-agent would use this other way for initial requests (e.g. if it wants to send a SUBSCRIBE), without impacting the routing of mid-dialog requests in home proxies. That system has advantages, but unfortunately, it also doesn't solve the real-world problems. The commonest example that we've been running into with our SIP PBX (open source: sipX, http://www.sipfoundry.org, commercial: SIPxchange, http://www.pingtel.com) is this: Caller Alice in domain A establishes a dialog with Callee Bob in domain B. The INVITE carries Contact: alice@domain.a. Bob's UA considers this URI, , to be the "remote target" of the dialog and publishes it as such in its dialog event package. Brian in domain B wishes to execute a 3rd-party call control operation on the dialog (e.g., "picking up" the call ringing on Bob's UA), so his UA subscribes to Bob's dialog event package, extracts the "remote target" element, and uses it to contact Alice's UA. The problem that arises is that Brian and Alice are in different domains, and it is crucial that -- the Contact in the original INVITE -- be a GRUU. If we were to create an alternative header for carrying Alice's GRUU, we would need to modify Alice's UA (to obtain the GRUU and put it into the Contact-GRUU header), modify Bob's UA (to extract the Contact-GRUU header and put it into the dialog event package as a "remote GRUU" element), and modify Brian's UA (to extract the "remote GRUU" element from the dialog event package). The current proposal only requires modifying Alice's UA. Also, given that most UA contact addresses aren't globally routable, the home proxy for domain A is probably already record-routed into the dialog, so the extra processing involved is only the GRUU lookup, not an extra transmission hop. Remember, what I am describing above is what we already see in the field at our users'/customers' sites, not a hypothetical. Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sun Aug 20 15:11:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEsfF-0004om-80; Sun, 20 Aug 2006 15:08:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEsfE-0004ll-2p for sip@ietf.org; Sun, 20 Aug 2006 15:08:52 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEsfC-0004DV-TB for sip@ietf.org; Sun, 20 Aug 2006 15:08:52 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2006082019085001400ggqfie>; Sun, 20 Aug 2006 19:08:50 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k7KJ8oWI002491 for ; Sun, 20 Aug 2006 15:08:50 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k7KJ8oEB002487; Sun, 20 Aug 2006 15:08:50 -0400 Date: Sun, 20 Aug 2006 15:08:50 -0400 Message-Id: <200608201908.k7KJ8oEB002487@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: <44D8E6B2.3040604@cisco.com> (jdrosen@cisco.com) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-gruu-10.txt References: <1ECE0EB50388174790F9694F77522CCF0BFA2E24@zrc2hxm0.corp.nortel.com> <44D8E6B2.3040604@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Jonathan Rosenberg It is true that SIP and SIPS URI are never equivalent based on URI comparison, but they always point to the same resource, and if one of them exists in a domain, so too does the other. [...] I'm really hoping to not have to figure out the whole sips mess to progress GRUU. >From an implementor's point of view, the sip/sips questions seem entirely orthogonal to the GRUU mechanisms. It's quite possible that the official rules for validity of sip and sips are flouted by many implementations, but for sanity's sake, everyone follows the rule: If both the sip and sips version of a URI are valid, (1) they route to the same resource (or collection of resources), and (2) and manipulation that affects the validity or the set of resources targeted by one automatically affects the other in exactly the same way. As the GRUU proposal follows the above rule of thumb, I don't see why we need to settle or take a stand on *any* sips question to progress this I-D. Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sun Aug 20 17:38:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEuwf-0001br-IL; Sun, 20 Aug 2006 17:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEuwe-0001bm-Bj for sip@ietf.org; Sun, 20 Aug 2006 17:35:00 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEuwd-0002uR-Vu for sip@ietf.org; Sun, 20 Aug 2006 17:35:00 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <20060820213459012002k6tle>; Sun, 20 Aug 2006 21:34:59 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k7KLYwWI006047; Sun, 20 Aug 2006 17:34:58 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k7KLYw4m006043; Sun, 20 Aug 2006 17:34:58 -0400 Date: Sun, 20 Aug 2006 17:34:58 -0400 Message-Id: <200608202134.k7KLYw4m006043@dragon.ariadne.com> From: Dale.Worley@comcast.net To: drage@lucent.com, dean.willis@softarmor.com In-reply-to: <5D1A7985295922448D5550C94DE291801E50FC@DEEXC1U01.de.lucent.com> (drage@lucent.com) References: <5D1A7985295922448D5550C94DE291801E50FC@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: sip@ietf.org Subject: [Sip] Re: Critical reviewers for draft-ietf-sip-gruu-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Here is my review. There is only one technical issue, and that one is minor. ---------------------------------------------------------------------- Item 1: - location in document Section 8.2.2. - nature of comment Editorial. Wording does not match intention of author (see author's comment below). Current wording is a significant technical problem. - comment >From the SIP mailing list: From: Jonathan Rosenberg > From: Dale Worley > In 8.2.2, I see "The rules in Section 8.1.1 ensure that at least one > proxy in the same domain of the home proxy will be visited." In the > context, it appears that this is stating that 8.1.1 ensures that a UA > in a domain that issues GRUUs will always have its UAs use an outbound > proxy. And yet I can't see how 8.1.1 forces that, especially in light > of the statement "Note that this specification does not require the > use of an outbound proxy". This is a bug. It should say that, if an outbound proxy is used at all, then the request will visit a proxy in the home domain. But, its valid to use gruu without any outbound proxies. - proposed fix Have the author correct the wording, as there seems to be no disagreement on the substance of the passage, in that I now agree that it is a bug in as Jonathan described it. Item 2: - location in document Section 6, figure 3 and section 12, figure 5. - nature of comment Editorial. - comment The two figures in the I-D are labeled "figure 3" and "figure 5", rather than the expected "figure 1" and "figure 2" (as in -09). - proposed fix Renumber figures as in -09. Item 3: - location in document Section 8.1.1. - nature of comment Editorial. - comment > When using a service route, > this requirement (that the GRUU be obtained from a domain that will > be visited by the request) it is sufficient to use the GRUU learned > in the same registration that delivered the service route. > > This doesn't parse. Possibly it should read "... to satisfy this > requirement (...), it is sufficient ...". - proposed fix As proposed by the author on the SIP mailing list: When using a service route, this requirement (that the GRUU be obtained from a domain that will be visited by the request) is readily met by using the GRUU learned in the same REGISTER response that delivered the service route. Item 4: - location in document Section 5. - nature of comment Editorial. - comment My comment: > Section 5, page 9: "that results from stripping out the "opaque" URI > parameter" s.b. "that results from stripping out the "opaque" and > "gruu" URI parameters". > But that isn't really the statement we want either, since URI > "equivalence" is not affected by a URI parameter present in one URI > and not in the other. See RFC 3261, section 19.1.4. That is, > > sip:carol@chicago.com > sip:carol@chicago.com;opaque="dRfHgbHjGhImBv";gruu > > are equivalent already. But unfortunately so are: > > sip:carol@chicago.com > sip:carol@chicago.com;opaque="dRfHgbHjGhImBv";gruu;hop-sip-and-jump > > and we want to rule out the latter pair. Author's response: > Interesting. What this means is that, based on URI equivalence, a GRUU > will in fact equal its AOR. Hmm. Its not obvious to me that this is a > bug or a feature. It really depends on what is a reasonable basis for > URI equality. One reasonable definition is that two URI should be > equivalent only if requests targeted towards them would reach the same > user, where 'same' refers to the ability to authenticate with a specific > credential. With that definition, the GRUU should be equal to the AOR > based on URI equality. > > Since I don't see any real issue with the AOR and GRUU being equal, I > think all we need to do is state that this is the fact. I changed the > paragraph we're talking about to read: > > > If the GRUU contains an "opaque" URI parameter, the URI that results > from stripping out the "opaque" and "gruu" URI parameters MUST be > equivalent to the AOR associated with the GRUU. Indeed, the GRUU > itself will also be equivalent to the AOR based on URI comparison, > since the "gruu" and "opaque" parameters will be ignored during > comparison, being present in one URI (the GRUU) and not the other (the > AOR). > - proposed fix I believe that I confused the issue in the exchange above, as the question is not a matter of a useful definition of "equivalence" (it's far too late to change that, anyway), but that in the passage, we probably don't want to use "equivalence" to describe the relationship between the GRUU and the AOR. I suggest: > If the GRUU contains an "opaque" URI parameter, the URI that results > from stripping out the "opaque" and "gruu" URI parameters MUST be > the AOR associated with the GRUU. Using "the same as" is probably stricter than we really need (as textual equality would not allow rearranging the order of URI parameters, and other trivial changes), but it ensures that implementations do not construct GRUUs that confuse other implementations. Whereas the current wording uses "equivalent", which allows gratuitously adding and deleting URI parameters. Item 5: - location in document Section 10. - nature of comment Minor technical. - comment My original comment: > Section 10, page 23: ""gruu" EQUAL LDQUOT (SIP-URI / SIPS-URI) > RDQUOT" is not what we want, I think. I think the semantics we are > looking for is ""gruu" EQUAL quoted-string, where the value > represented by the quoted-string is a SIP-URI or SIPS-URI". (That > latter could be represented in BNF, but that would make it less > clear.) > Due to the details of the grammar, the new formulation differs from > the original only in some unusual cases, such as allowing: > > Contact: <...>;gruu="sip:gruu\~123456789@example.com;gruu" > > (The GRUU is .) > > But it seems to me that it is non-orthogonal (and inviting trouble) to > have the grammar for c-p-gruu forbid backslash-escapes of characters > that do not require them, when the grammar for generic-param allows > them. Author's response: > Egads. I disagree here. The SIP URI itself cannot contain a quote, so > there is no need to ever use backslash escaping. I think folks might get > confused by backslash escaping here. If you just put the unescaped URI > in, you'll never have a problem. Why allow escaping? My response: I see it as a dangerous thing to introduce differing rules as to what escaping is allowed and forbidden in different parameters. As a matter of layering, it should be possible to write a parser that can correctly parse the values of all parameters, and conversely, a composer that can correctly represent any set of values for any parmeters, and neither should require special knowledge of any particular parameters. (Note that the grammar of RFC 3261 adhered to this principle.) Since in the general case, RFC 3261 allows, e.g., a parameter value of "a~b" to be represented > Contact: <...>;unknown-parameter="a\~b" Then it should be acceptable to escape any occurrence of "~" in any header-parameter using "\", as in the case in my original comment. Otherwise, the parser and composer for name-addr's will need continual tweaking to accomodate the special restrictions of each newly standardized header-parameter. In this case, the composer needs to know that while the generic grammar allows any character that can appear in a value to be escaped with "\" (and for a few, it is mandatory), that in the gruu parameter, escaping is forbidden. (Although unfortunately, this principle is already violated in regard to string-value's in feature-param's (RFC 3840), where the header-parameter value must contain an unescaped "<", followed by the string value itself, and then an unescaped ">", but any occurrences of "<" and ">" in the string value must be escaped "\". And those rules provide no practical benefit, as a general URI parser must already be able to handle both escaped and un-escaped "<" and ">" in all positions within quoted header-parameter values.) - proposed fix Substitute: c-p-gruu = "gruu" EQUAL quoted-string This would imply that c-p-gruu is to be intrpreted as any other quoted-string that is the value of a header-parameter. That the value represented by the quoted-string is a sip or sips URI is not enforced by this grammar, but is stated elsewhere in the document. Item 6: - location in document Section 12. - nature of comment Editorial. - comment Example messages are indented by different amounts. Continuation line of header is missing its initial whitespace (or an construction was omitted) in the example at the bottom of page 30: Contact: ;+sip.instance="" - proposed fix Indent the example messages consistently. Correct the presentation of the split Contact header. ---------------------------------------------------------------------- Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 21 05:30:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF61l-0000AG-Vo; Mon, 21 Aug 2006 05:25:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF61k-00009y-Rg for sip@ietf.org; Mon, 21 Aug 2006 05:25:00 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF61f-0000YO-1b for sip@ietf.org; Mon, 21 Aug 2006 05:25:00 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k7L9OoKu019745; Mon, 21 Aug 2006 11:24:50 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k7L9OnTW023562; Mon, 21 Aug 2006 11:24:49 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 11:24:49 +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 Subject: AW: [Sip] comments on draft-ietf-sip-saml-00 Date: Mon, 21 Aug 2006 11:24:49 +0200 Message-ID: In-Reply-To: <44AEB61F.2020108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-ietf-sip-saml-00 Thread-Index: Acah+8GUgkN36t/NTb60BGwfs1jfCAjATAng From: "Tschofenig, Hannes" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 21 Aug 2006 09:24:49.0792 (UTC) FILETIME=[A6A32000:01C6C503] X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan,=20 thanks for your feedback. I noticed that I never replied to your mail.=20 Please find my response below:=20 =20 > -----Urspr=FCngliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Gesendet: Freitag, 7. Juli 2006 21:30 > An: IETF SIP List > Betreff: [Sip] comments on draft-ietf-sip-saml-00 >=20 > Overall, this is a HUGE improvement over=20 > draft-tschofenig-sip-saml-04,=20 > which is the last version I read (I see that -05 was similar to=20 > draft-ietf-sip-saml). This looks like a viable solution=20 > overall, and I=20 > like how it dovetails with sip-identity. >=20 >=20 >=20 > Major comments: >=20 > * I'm a little worried that the SAML assertion itself doesn't include=20 > any content from the SIP message which clearly limits its scope of=20 > applicability to the request. You are relying on authentication via=20 > sip-identity for that, but there are attacks where this won't work. >=20 > For example, consider a rogue proxy or MITM which sees a SIP=20 > request fly=20 > by. The AS was executed by an upstream proxy, so this request has an=20 > Identity and Identity-Info header field. The proxy modifies the=20 > Indentity-Info header field, which contains a URL to an older=20 > assertion=20 > generated by the AS for the same subject, say, for a previous call it=20 > just made. >=20 > This is not a major threat, but there may be others like it. Is there=20 > harm in including things like call-id, contact and other=20 > parameters into=20 > the saml assertion so they are signed too? I fully agree with you.=20 >=20 > * I'm not clear on how this mechanism works with older sip-identity=20 > implementations. The main issue is whether the URI in the=20 > identity-info=20 > header field will return just a certificate, as specified in=20 > sip-identity, or whether it returns a saml assertion. An older=20 > sip-identity verifier will expect a certificate but it will get an=20 > assertion if the AS implements sip-saml. Perhaps you are=20 > assuming that=20 > the Accept headers or something are used for this? Somehow=20 > this needs to=20 > be handled. My understanding was that this got fixed with the SIP Identity draft. I = might, however, be worth to double-check it.=20 >=20 >=20 > > 6.1.4.1.3. Element: > > > > The element SHOULD contain an > > element, which itself SHOULD contain an element. The > > value of the element SHOULD be the same as=20 > the addr-spec > > of the SIP request's To header field. >=20 > Hmm. Here is our infamous retargeting problem again. If the=20 > request is=20 > retargeted, does this mean that the assertion cannot be used by the=20 > forwarded party? This restriction doesn't exist for normal=20 > sip-identity. That's a good point. This is somewhat a difficult problem: Ideally, you = would like to use the assertion in a very flexible way. By doing this = you introduce some security problems (since the assertion can be re-used = or use outside a context that was somehow envisioned). If you put some = restrictions into the assertion then experience these types of problems. = >=20 >=20 > Minor comments: >=20 > > The scope of this specification is: > >=20 > > o Specify a SIP profile of SAML -- aka a "SIP SAML=20 > profile" -- such > > that a subject's profile attributes, and their domain's > > certificate, can be conveyed to a relying party using=20 > SAML. In > > doing so, satisfy the requirements outlined in=20 > [I-D.ietf-sipping- > > trait-authz], and compose with [I-D.ietf-sip-identity]. >=20 > perhaps I've misunderstood, but don't we also need to specify=20 > a SIP SAML=20 > binding? Yes; we need to specify a binding an a profile.=20 >=20 > > SIP-specific SAML profile(s) and binding(s). This is technically > > straigh-forward as both SAML and SIP are explicitly extensible. >=20 > straightforward fixed.=20 >=20 > > [RFC3261]. Depending on the chosen SIP security mechanism > > either digest authentication, S/MIME or Transport Layer > > Security is used to provide the AS with a strong=20 > assurance > > about the identity of Alice. >=20 > well, TLS in this use case is not normally used to provide=20 > the AS with=20 > the identity of ALice. It depends how you use TLS.=20 > Perhaps you are referring to mutual=20 > authentication with tls? Yes.=20 > Or maybe you just mean digest over tls? Maybe we need to phrase the sentence differently but we referred here = mainly to the client authentication mechanisms.=20 What about the following sentence: " Depending on the chosen SIP security mechanism for client authentication = either digest authentication, client side authentication of Transport = Layer Security, or a combination of both is used to provide the AS with = a strong assurance about the identity of Alice. " >=20 > > signature" for the message and add Identity and Identity-Info > > headers to the message. The AS also at this=20 > time constructs >=20 > I feel like a broken record, but its header field and not header >=20 fixed.=20 >=20 > * sections 6.1.3, 6.1.2 and 5 all seem pretty redundant, as=20 > they contain=20 > the same flow with nearly the same levels of detail. Are all=20 > three needed? Hmmm. Maybe we can shorten the draft here a bit.=20 We previously had more functionality in the draft. A lot of it got = removed to get more specific with some parts of the document (but might = be added again later). =20 >=20 >=20 > > Attribute: NotOnOrAfter > >=20 > > The value of the NotOnOrAfter XML attribute MUST be=20 > set to a time > > instant later than the value for NotBefore. >=20 > guidance on how to set this? >=20 > > This section specifies the "SAML HTTP-URI-based SIP Binding", > > (SHUSB). >=20 > SHUSB? Geez, this acronym is awful. Do you have an idea for a nice acronym?=20 >=20 > > Section 3.7.5.4 Error Reporting: > >=20 > > All SHOULDs in this section are to be interpreted as MUSTs. > >=20 >=20 > This is somewhat mysterious. Is there something SIP specific=20 > which would=20 > cause you to want to do this, or just a beef with the fact that=20 > everything there is a SHOULD and not a MUST? Also perhaps a few words=20 > about whats in that section would be helpful. >=20 > Indeed its not obvious to me why we can't just use the=20 > existing SAML URI=20 > binding if we're just doing a vanilla http query to retrieve=20 > the assertion. With the restrictions listed in this section you define a new profile. There is, however, the question why these restrictions are so important. = To me it sounds reasonable to just put MUST (instead of a SHOULD) in the = text about error reporting:=20 " 3.7.5.4 Error Reporting As an HTTP protocol exchange, the appropriate HTTP status code SHOULD be = used to indicate the result of a request. For example, a SAML responder = that refuses to perform a message exchange with the SAML requester = SHOULD return a "403 Forbidden" response. If the assertion specified is = unknown to the responder, then a "404 Not Found" response SHOULD be = returned. In these cases, the content of the HTTP body is not = significant. " There still remains the question why the SAML guys have written the text = with a SHOULD in the first place. Maybe Jeff can help us here.=20 >=20 > > The value of the element MUST be the same as the Address of > > Record (AoR) value used in computing the "signed-identity-digest" > > which forms the value of the Identity header. See Section 9 of > > [I-D.ietf-sip-identity]. >=20 > I read this as being that this is the literal AoR, i.e.,=20 > sip:user@domain. But, in the example later on: >=20 > > 1 > 2 IssueInstant=3D"2003-04-17T00:46:02Z" Version=3D"2.0" > > 3 xmlns=3D"urn:oasis:names:tc:SAML:2.0:assertion"> > > 4 > > 5 example.com > > 6 > > 7 > > 8 > 9 Format=3D > > 10 =20 > "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> > > 11 Alice@example.com > > 12 >=20 > there is no sip:, and the format attribute has a URN which explicitly=20 > says emailAddress and not SIPURI. I think this should be a SIP URI. I think we need to define a few new SIP specific formats in here. I = wouldn't want to overloa the emailAddress field here.=20 Would that be OK for you?=20 Ciao Hannes PS: I have created a few new issues in the issue tracker at:=20 http://www.tschofenig.priv.at:8080/saml-sip I will speak to my co-authors about updating the document. Then, I will = get back to you and the group.=20 >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 21 11:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBTd-0005rU-Me; Mon, 21 Aug 2006 11:14:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBTc-0005pZ-MW for sip@ietf.org; Mon, 21 Aug 2006 11:14:08 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFBTa-0002FO-DW for sip@ietf.org; Mon, 21 Aug 2006 11:14:08 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 21 Aug 2006 08:14:06 -0700 X-IronPort-AV: i="4.08,151,1154934000"; d="scan'208"; a="1849263120:sNHT32322522" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7LFE5ra002759; Mon, 21 Aug 2006 08:14:05 -0700 Received: from [192.168.1.3] (sjc-vpn4-558.cisco.com [10.21.82.46]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7LFDn6b003831; Mon, 21 Aug 2006 08:14:05 -0700 (PDT) In-Reply-To: <7.0.1.0.0.20060808214436.0403fdc0@stevecrocker.com> References: <44D8E4E7.9060801@cisco.com> <62B9B0847CC47543B6B3B5E26BD268E60DB9B326@zrc2hxm2.corp.nortel.com> <7.0.1.0.0.20060808214436.0403fdc0@stevecrocker.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86CB63AC-56AD-4145-AD87-38CE98C51080@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Ciphersuites in SIP Date: Fri, 18 Aug 2006 17:05:37 -0700 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=750; t=1156173245; x=1157037245; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Ciphersuites=20in=20SIP; X=v=3Dcisco.com=3B=20h=3DlJdhKimynOyi9tEqS2nMIAz6tCE=3D; b=SiLEpnXy1v39sbwhULzJfbu6EPKcRIZXjl/kqm8nJedbB1YFFhB+tlBFbNofNgN0j8qq00Az 7GM+eoctAV7O233IB9kjpv8t70w7aBBcutK+vvGUybRjzIjcIoWfjFjR; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 8, 2006, at 6:48 PM, Joel M. Halpern wrote: > The proxies don't belong to the end user. Heck, with the way > things work in practice, the end user may not even know about the > proxies. And very often neither end user has a contractual > relationship with the intermediate proxies. 100% agree. That is why I don't see how you can't provide user security using a k,,hop by hop mechanism. If you want user integrity, you can get that to some degree with Identity. If you want confidentially as well, pretty much S/MIME is the only thing that might provide this today. (And I agree with Dean's chair comment that we need a use case for the problem to solve before we get too excited about the solution :-) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 21 11:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBUT-0005xM-NL; Mon, 21 Aug 2006 11:15:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBUS-0005xE-As for sip@ietf.org; Mon, 21 Aug 2006 11:15:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF9QO-0000BK-Sb for sip@ietf.org; Mon, 21 Aug 2006 09:02:40 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF9JQ-00077k-0M for sip@ietf.org; Mon, 21 Aug 2006 08:55:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Aug 2006 05:55:27 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,151,1154934000"; d="scan'208"; a="37187168:sNHT25989000" 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.20060308/8.12.11) with ESMTP id k7LCtRUU032724; Mon, 21 Aug 2006 08:55:27 -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.12.10/8.12.6) with ESMTP id k7LCtRuI004644; Mon, 21 Aug 2006 08:55:27 -0400 (EDT) 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, 21 Aug 2006 08:55:26 -0400 Received: from [10.86.242.53] ([10.86.242.53]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 08:55:26 -0400 Message-ID: <44E9AD3E.6040307@cisco.com> Date: Mon, 21 Aug 2006 08:55:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 References: <6FC4416DDE56C44DA0AEE67BC7CA43710FFFEB28@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710FFFEB28@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 12:55:26.0551 (UTC) FILETIME=[12BB8670:01C6C521] DKIM-Signature: a=rsa-sha1; q=dns; l=6368; t=1156164927; x=1157028927; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-ietf-sip-gruu-10 |To:Brian=20Stucker=20; X=v=3Dcisco.com=3B=20h=3DIhYcytQwHYv3ZD0NF3ad3b/43PQ=3D; b=bYr7Gl6qektARJLHdtNEXUgP1NAfqwDFL2RMv7PqTtN1rhAI1eHL8YVWH3n1q4dQJZq3hUwu bcfQobBCWd3W5ytedeNx6n9GGtpPVbqBEShva4x9JR15VK9HxtqAVjMR; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Stucker wrote: > I don't view it as being in the business of defining services, but the > business of defining interoperability. I believe that is in scope of the > IETF. > > What I'm concerned about is that a proxy is going to take license with > the operation of the protocol. If there's a legitimate case for having a > GRUU route to an alternate destination (which I think there likely is, > ie. voicemail) This already highlights the issue. IMO voicemail is *not* a legitimate case for having a gruu route to an alternate destination. At least not unless it was routed all the way to the UA, and then the UA chose to redirect it to VM. The cases I consider legit are when the caller is not going to be permitted access to the target at all. In that case I think it preferable to simply return an error. But I wouldn't fight too hard if somebody decided to forward to an announcement server in that case. > and there needs to be a way of preventing that so an > application can tell the proxy that it should strictly route to the GRUU > address and nowhere else I think the use of a gruu is already saying this as strongly as it makes sense to say anything. It is stating the caller's desires. > (which I think there likely is a need) then we > should specify the mechanism by which this can be done, and not the > application. I guess the callerprefs Request-Disposition header could be used to further say this. But there is still nothing to prevent a proxy for ignoring that as well. The fact is that callee policy will always trump caller policy in this regard. Paul > It would be a shame to wind up with "loose-routing" GRUUs after the > fact. > > Regards, > Brian > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, August 16, 2006 8:09 AM >> To: Stucker, Brian (RICH1:B620) >> Cc: Eric Rescorla; sip@ietf.org >> Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 >> >> >> >> Brian Stucker wrote: >>> Hmm.. I beg to differ from the "local policy" argument about >>> forwarding services and GRUUs. >>> >>> If a GRUU is generally subject to the same type of routing as a >>> non-GRUU URI, then what's the point of having a GRUU? So >> you can guess >>> as to what the heck the proxy is going to do with it? Maybe >> it'll act >>> like a GRUU.... Maybe it won't... >> I would prefer not to leave it so vague. But I don't know >> what else we can do unless we go into the business of >> defining services. >> >> Its not that we want gruus to be treated the same as AORs. >> Its just that when you start to look at real services you >> discover that some of them are applicable to gruus and some >> are not. When we aren't defining the services, we must leave >> it to those who are to decide for each service whether it >> applies to gruus or not. >> >> The ones identified so far that seem applicable are the ones >> that perform authorization. It should still be possible to >> refuse a caller from reaching the target of the gruu. >> >> Paul >> >>> We already have a mechanism for SIP URIs that don't act >> like a GRUU, >>> they're called AORs. If someone wants their requests to >> route like an >>> AOR, then they should return an AOR, and not a GRUU. >>> >>> Regards, >>> Brian >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, August 15, 2006 4:54 PM >>>> To: Eric Rescorla >>>> Cc: sip@ietf.org >>>> Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 >>>> >>>> Eric raised a lot of issues. I've been waiting to see Jonathan's >>>> response. Meanwhile I'll try to add my opinion about a couple of >>>> them. >>>> >>>> Paul >>>> >>>> Eric Rescorla wrote: >>>> >>>>> Why is it necessary to have GRUUs which are (1) >>>> identifiable as GRUUs >>>>> to peers but (2) can't be translated back to the AOR by the peer? >>>> A use case might help here: >>>> >>>> - Bob has an "unlisted" AOR. >>>> - Alice calls Bob. (She knows the AOR.) >>>> - Alice does a transfer, >>>> transferring Charlie to Bob, replacing Alice:Bob call >>>> >>>> To do this, Alice sends a REFER to Charlie, with a Refer-To >>>> containing the contact URI from her dialog with Bob. >>>> >>>> Bob doesn't want Charlie to be able to learn his AOR as a >> result of >>>> this. If Bob uses a gruu obtained from the registrar for >> his AOR, he >>>> doesn't want Charlie to be able to reconstruct the AOR from it. >>>> >>>> Note that the peer (Alice) that first receives this gruu >> knows what >>>> AOR it is associated with, because she called it. >>>> This correlation is not available when the request gets to another >>>> peer - Charlie. >>>> >>>>> However, forwarding services, such as call forwarding, >>>> SHOULD NOT be >>>>> provided for requests sent to a GRUU. The intent of the >>>> GRUU is to >>>>> target a specific UA instance, and this is incompatible with >>>>> forwarding operations. >>>>> >>>>> This seems to me to get into policy. Are you saying that I >>>> can't have >>>>> my cell phone forward calls to some other phone just cause >>>> people call >>>>> my cell number rather than my generic "EKR" AOR? >>>> One intent of a gruu is to identify a specific UA >> instance. A service >>>> that ignores that intent will in general be counter productive. >>>> >>>> But this is a gray area, and so it is hard to state a precise yet >>>> general rule that can be used to decide whether a >> particular service >>>> should be applied to a request targeting a gruu. I think all the >>>> draft can do is sensitize developers to the issue, so that >> they think >>>> carefully about it regarding each service. >>>> >>>> The target UA itself can also decide to forward if it wants. >>>> But again it ought to take the intent into account. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 21 11:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBTd-0005rU-Me; Mon, 21 Aug 2006 11:14:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBTc-0005pZ-MW for sip@ietf.org; Mon, 21 Aug 2006 11:14:08 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFBTa-0002FO-DW for sip@ietf.org; Mon, 21 Aug 2006 11:14:08 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 21 Aug 2006 08:14:06 -0700 X-IronPort-AV: i="4.08,151,1154934000"; d="scan'208"; a="1849263120:sNHT32322522" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7LFE5ra002759; Mon, 21 Aug 2006 08:14:05 -0700 Received: from [192.168.1.3] (sjc-vpn4-558.cisco.com [10.21.82.46]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7LFDn6b003831; Mon, 21 Aug 2006 08:14:05 -0700 (PDT) In-Reply-To: <7.0.1.0.0.20060808214436.0403fdc0@stevecrocker.com> References: <44D8E4E7.9060801@cisco.com> <62B9B0847CC47543B6B3B5E26BD268E60DB9B326@zrc2hxm2.corp.nortel.com> <7.0.1.0.0.20060808214436.0403fdc0@stevecrocker.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86CB63AC-56AD-4145-AD87-38CE98C51080@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Ciphersuites in SIP Date: Fri, 18 Aug 2006 17:05:37 -0700 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=750; t=1156173245; x=1157037245; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Ciphersuites=20in=20SIP; X=v=3Dcisco.com=3B=20h=3DlJdhKimynOyi9tEqS2nMIAz6tCE=3D; b=SiLEpnXy1v39sbwhULzJfbu6EPKcRIZXjl/kqm8nJedbB1YFFhB+tlBFbNofNgN0j8qq00Az 7GM+eoctAV7O233IB9kjpv8t70w7aBBcutK+vvGUybRjzIjcIoWfjFjR; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 8, 2006, at 6:48 PM, Joel M. Halpern wrote: > The proxies don't belong to the end user. Heck, with the way > things work in practice, the end user may not even know about the > proxies. And very often neither end user has a contractual > relationship with the intermediate proxies. 100% agree. That is why I don't see how you can't provide user security using a k,,hop by hop mechanism. If you want user integrity, you can get that to some degree with Identity. If you want confidentially as well, pretty much S/MIME is the only thing that might provide this today. (And I agree with Dean's chair comment that we need a use case for the problem to solve before we get too excited about the solution :-) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 21 11:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBUT-0005xM-NL; Mon, 21 Aug 2006 11:15:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBUS-0005xE-As for sip@ietf.org; Mon, 21 Aug 2006 11:15:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF9QO-0000BK-Sb for sip@ietf.org; Mon, 21 Aug 2006 09:02:40 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF9JQ-00077k-0M for sip@ietf.org; Mon, 21 Aug 2006 08:55:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Aug 2006 05:55:27 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,151,1154934000"; d="scan'208"; a="37187168:sNHT25989000" 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.20060308/8.12.11) with ESMTP id k7LCtRUU032724; Mon, 21 Aug 2006 08:55:27 -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.12.10/8.12.6) with ESMTP id k7LCtRuI004644; Mon, 21 Aug 2006 08:55:27 -0400 (EDT) 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, 21 Aug 2006 08:55:26 -0400 Received: from [10.86.242.53] ([10.86.242.53]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 08:55:26 -0400 Message-ID: <44E9AD3E.6040307@cisco.com> Date: Mon, 21 Aug 2006 08:55:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 References: <6FC4416DDE56C44DA0AEE67BC7CA43710FFFEB28@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710FFFEB28@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 12:55:26.0551 (UTC) FILETIME=[12BB8670:01C6C521] DKIM-Signature: a=rsa-sha1; q=dns; l=6368; t=1156164927; x=1157028927; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-ietf-sip-gruu-10 |To:Brian=20Stucker=20; X=v=3Dcisco.com=3B=20h=3DIhYcytQwHYv3ZD0NF3ad3b/43PQ=3D; b=bYr7Gl6qektARJLHdtNEXUgP1NAfqwDFL2RMv7PqTtN1rhAI1eHL8YVWH3n1q4dQJZq3hUwu bcfQobBCWd3W5ytedeNx6n9GGtpPVbqBEShva4x9JR15VK9HxtqAVjMR; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Stucker wrote: > I don't view it as being in the business of defining services, but the > business of defining interoperability. I believe that is in scope of the > IETF. > > What I'm concerned about is that a proxy is going to take license with > the operation of the protocol. If there's a legitimate case for having a > GRUU route to an alternate destination (which I think there likely is, > ie. voicemail) This already highlights the issue. IMO voicemail is *not* a legitimate case for having a gruu route to an alternate destination. At least not unless it was routed all the way to the UA, and then the UA chose to redirect it to VM. The cases I consider legit are when the caller is not going to be permitted access to the target at all. In that case I think it preferable to simply return an error. But I wouldn't fight too hard if somebody decided to forward to an announcement server in that case. > and there needs to be a way of preventing that so an > application can tell the proxy that it should strictly route to the GRUU > address and nowhere else I think the use of a gruu is already saying this as strongly as it makes sense to say anything. It is stating the caller's desires. > (which I think there likely is a need) then we > should specify the mechanism by which this can be done, and not the > application. I guess the callerprefs Request-Disposition header could be used to further say this. But there is still nothing to prevent a proxy for ignoring that as well. The fact is that callee policy will always trump caller policy in this regard. Paul > It would be a shame to wind up with "loose-routing" GRUUs after the > fact. > > Regards, > Brian > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, August 16, 2006 8:09 AM >> To: Stucker, Brian (RICH1:B620) >> Cc: Eric Rescorla; sip@ietf.org >> Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 >> >> >> >> Brian Stucker wrote: >>> Hmm.. I beg to differ from the "local policy" argument about >>> forwarding services and GRUUs. >>> >>> If a GRUU is generally subject to the same type of routing as a >>> non-GRUU URI, then what's the point of having a GRUU? So >> you can guess >>> as to what the heck the proxy is going to do with it? Maybe >> it'll act >>> like a GRUU.... Maybe it won't... >> I would prefer not to leave it so vague. But I don't know >> what else we can do unless we go into the business of >> defining services. >> >> Its not that we want gruus to be treated the same as AORs. >> Its just that when you start to look at real services you >> discover that some of them are applicable to gruus and some >> are not. When we aren't defining the services, we must leave >> it to those who are to decide for each service whether it >> applies to gruus or not. >> >> The ones identified so far that seem applicable are the ones >> that perform authorization. It should still be possible to >> refuse a caller from reaching the target of the gruu. >> >> Paul >> >>> We already have a mechanism for SIP URIs that don't act >> like a GRUU, >>> they're called AORs. If someone wants their requests to >> route like an >>> AOR, then they should return an AOR, and not a GRUU. >>> >>> Regards, >>> Brian >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, August 15, 2006 4:54 PM >>>> To: Eric Rescorla >>>> Cc: sip@ietf.org >>>> Subject: Re: [Sip] Comments on draft-ietf-sip-gruu-10 >>>> >>>> Eric raised a lot of issues. I've been waiting to see Jonathan's >>>> response. Meanwhile I'll try to add my opinion about a couple of >>>> them. >>>> >>>> Paul >>>> >>>> Eric Rescorla wrote: >>>> >>>>> Why is it necessary to have GRUUs which are (1) >>>> identifiable as GRUUs >>>>> to peers but (2) can't be translated back to the AOR by the peer? >>>> A use case might help here: >>>> >>>> - Bob has an "unlisted" AOR. >>>> - Alice calls Bob. (She knows the AOR.) >>>> - Alice does a transfer, >>>> transferring Charlie to Bob, replacing Alice:Bob call >>>> >>>> To do this, Alice sends a REFER to Charlie, with a Refer-To >>>> containing the contact URI from her dialog with Bob. >>>> >>>> Bob doesn't want Charlie to be able to learn his AOR as a >> result of >>>> this. If Bob uses a gruu obtained from the registrar for >> his AOR, he >>>> doesn't want Charlie to be able to reconstruct the AOR from it. >>>> >>>> Note that the peer (Alice) that first receives this gruu >> knows what >>>> AOR it is associated with, because she called it. >>>> This correlation is not available when the request gets to another >>>> peer - Charlie. >>>> >>>>> However, forwarding services, such as call forwarding, >>>> SHOULD NOT be >>>>> provided for requests sent to a GRUU. The intent of the >>>> GRUU is to >>>>> target a specific UA instance, and this is incompatible with >>>>> forwarding operations. >>>>> >>>>> This seems to me to get into policy. Are you saying that I >>>> can't have >>>>> my cell phone forward calls to some other phone just cause >>>> people call >>>>> my cell number rather than my generic "EKR" AOR? >>>> One intent of a gruu is to identify a specific UA >> instance. A service >>>> that ignores that intent will in general be counter productive. >>>> >>>> But this is a gray area, and so it is hard to state a precise yet >>>> general rule that can be used to decide whether a >> particular service >>>> should be applied to a request targeting a gruu. I think all the >>>> draft can do is sensitize developers to the issue, so that >> they think >>>> carefully about it regarding each service. >>>> >>>> The target UA itself can also decide to forward if it wants. >>>> But again it ought to take the intent into account. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 21 14:16:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEHL-0000eX-9j; Mon, 21 Aug 2006 14:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEHK-0000cG-8i for sip@ietf.org; Mon, 21 Aug 2006 14:13:38 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFE6b-00005Y-U7 for sip@ietf.org; Mon, 21 Aug 2006 14:02:38 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7LI2P012386; Mon, 21 Aug 2006 14:02:25 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Mon, 21 Aug 2006 13:02:22 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DEE33C2@zrc2hxm2.corp.nortel.com> In-Reply-To: <86CB63AC-56AD-4145-AD87-38CE98C51080@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: AcbFNWGcYf0pXNvKRI+1GA5Vf9se5wADijZg From: "Samir Srivastava" To: "Cullen Jennings" , "Joel M. Halpern" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, As AD jumped into, my replies on the comments received so far. 1) I am looking into the Dean's comment from the regulatory perspective. If Regulator's doesn't allow to view the cipher-suite of the earlier hop to be viewed by the other proxies, then how MTA's are putting that ? Or they are not complying with this. As the complete message contents are visible to the next hop proxy, viewing the cipher-suite used at the earlier hop should not be an issue. It's my hunch only, I have to still verify it. 2) There is cheater proxy case apart from the misconfiguration etc, which I mentioned in the earlier arguments. It will be useful there. 3) I agree that end user doesn't have the contractual agreement with the providers/proxies in the hops further down. But the security-level agreement with the end user and his home proxy should be honored by the middle hops if end-user is particular about the AES256 as of now.=20 4) Jonathan suggested the usage of tool where Periodicity of check is the bottleneck. Vendors have different way of logging. In the multi-vendor deployment scenarios with upgrades etc, it will be real hard to keep this information in sync without leaving a time window of less secure hops. The other ways of sending the clear text messages by the proxies can be fixed by configuration etc. But this needs a mechanism in the protocol, if we agree on the problem definition. 5) The proposed solution is extensible to DTLS or any other future extensions for security protocol, where SIPS in its current definition of transport parameter is broken. We can add a new parameter secure-protocol in the URI definition or extend the transport parameter to TLS+TCP, DTLS+DCCP, DTLS+UDP etc as suggested earlier in the wacky thread. 6) How many S/MIME deployments are there ? I will modify the draft with the stress on the problem after having definitive answer to 1), and see if group has further interest. Thx Samir > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, August 18, 2006 5:06 PM > To: Joel M. Halpern > Cc: Srivastava, Samir (SC100:8826); Jonathan Rosenberg; SIP > Subject: Re: [Sip] Ciphersuites in SIP >=20 >=20 > On Aug 8, 2006, at 6:48 PM, Joel M. Halpern wrote: >=20 > > The proxies don't belong to the end user. Heck, with the way > > things work in practice, the end user may not even know about the > > proxies. And very often neither end user has a contractual > > relationship with the intermediate proxies. >=20 > 100% agree. That is why I don't see how you can't provide user > security using a k,,hop by hop mechanism. If you want user integrity, > you can get that to some degree with Identity. If you want > confidentially as well, pretty much S/MIME is the only thing that > might provide this today. >=20 > (And I agree with Dean's chair comment that we need a use case for > the problem to solve before we get too excited about the solution :-) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 21 15:28:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFOg-0008Ol-7t; Mon, 21 Aug 2006 15:25:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFOe-0008OS-Vt for sip@ietf.org; Mon, 21 Aug 2006 15:25:16 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFFOd-0006o4-N5 for sip@ietf.org; Mon, 21 Aug 2006 15:25:16 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k7LJPB0D009906 for ; Mon, 21 Aug 2006 14:25:11 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k7LJP6f08342; Mon, 21 Aug 2006 14:25:11 -0500 (CDT) Message-ID: <44EA0891.6080909@lucent.com> Date: Mon, 21 Aug 2006 14:25:05 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SIP LIST Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] Updated revision of connect-reuse (draft-ietf-sip-connect-reuse-06) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks: On behalf of my co-authors, I have just submitted the latest revision (-06) to draft-ietf-sip-connect-reuse. This version should (hopefully) get the draft out of the WGLC state. It addresses the concerns and comments raised during the WGLC period, including support for name-based virtual servers across TCP and TLS. The text has been also redone for readability. More attention is paid to TCP connection reuse than was the case with the previous versions. Until the archive is updated with the new version, you can get a copy from: http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-06.html http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-06.txt Please go through the draft and advise regarding comments you may have. As the co-author holding the editor's pen, I believe that the draft is ready to proceed further. I will wait to hear from the chairs about the next steps for this particular document. Thank you. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 21 16:33:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGPQ-000769-3f; Mon, 21 Aug 2006 16:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGPN-0006hD-E9 for sip@ietf.org; Mon, 21 Aug 2006 16:30:05 -0400 Received: from [2001:5c0:8fff:fffe::4c3d] (helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFGM2-0008Ms-Mx for sip@ietf.org; Mon, 21 Aug 2006 16:26:40 -0400 Received: from [192.168.0.106] (pool-71-164-175-25.dllstx.fios.verizon.net [71.164.175.25]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k7LKQBZN001468 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 21 Aug 2006 15:26:16 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B87277A-D19C-43D2-987B-C8DEA01456D2@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Mon, 21 Aug 2006 15:26:10 -0500 To: IETF SIP List X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip-chairs@tools.ietf.org Subject: [Sip] GRUU-10: "gruu" as both a header and URI parameter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've got several comments for the gruu spec for today's deadline, and will meet Keith's formatting requirement for them in other messages. There are a couple of topics I wanted to start individual threads on though. Here's the first: Right now, the mechanism is creating a header parameter and a URI parameter with the same name : "gruu". Thinking about this from the perspective of debugging things in a lab, or worse, over VoIP or an IM, I envision many, many conversations that will take this form: A: I see the problem - it's in the gruu parameter. B: Ok - I'll change that (retry) A: It's still broken - I don't see what you... Oh wait - I didn't mean _that_ gruu parameter, go change the other one. B: Oh crud - was it the header parameter or the URI parameter? (and which one of those is outside the <>'s? I can never keep that straight...) For the sake of sanity (at least mine), could we please reconsider giving these things different names? RjS _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 21 16:45:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGc8-0004ab-LN; Mon, 21 Aug 2006 16:43:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGc6-0004ZP-TF for sip@ietf.org; Mon, 21 Aug 2006 16:43:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFGc0-0004QP-Cw for sip@ietf.org; Mon, 21 Aug 2006 16:43:14 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A3F478E0001; Mon, 21 Aug 2006 22:43:01 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 22:46:11 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 22:43:01 +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 Subject: RE: [Sip] GRUU-10: "gruu" as both a header and URI parameter Date: Mon, 21 Aug 2006 22:43:00 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F139F@esealmw113.eemea.ericsson.se> In-Reply-To: <2B87277A-D19C-43D2-987B-C8DEA01456D2@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU-10: "gruu" as both a header and URI parameter Thread-Index: AcbFYQ8erFCywktXTM+7fFTDUnltWgAAQlGw From: "Christer Holmberg \(JO/LMF\)" To: "Robert Sparks" , "IETF SIP List" X-OriginalArrivalTime: 21 Aug 2006 20:43:01.0122 (UTC) FILETIME=[648F5620:01C6C562] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip-chairs@tools.ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, As part of the outbound discussion I asked whether it would be possible to use the same name for the header and URI parameter indicating support for STUN keep-alive. Regards, Christer=20 -----Original Message----- From: Robert Sparks [mailto:rjsparks@estacado.net]=20 Sent: 21. elokuuta 2006 23:26 To: IETF SIP List Cc: sip-chairs@tools.ietf.org Subject: [Sip] GRUU-10: "gruu" as both a header and URI parameter I've got several comments for the gruu spec for today's deadline, and will meet Keith's formatting requirement for them in other messages. There are a couple of topics I wanted to start individual threads on though. Here's the first: Right now, the mechanism is creating a header parameter and a URI parameter with the same name : "gruu". Thinking about this from the perspective of debugging things in a lab, or worse, over VoIP or an IM, I envision many, many conversations that will take this form: A: I see the problem - it's in the gruu parameter. B: Ok - I'll change that (retry) A: It's still broken - I don't see what you... Oh wait - I didn't mean _that_ gruu parameter, go change the other one. B: Oh crud - was it the header parameter or the URI parameter? (and which one of those is outside the <>'s? I can never keep that straight...) For the sake of sanity (at least mine), could we please reconsider giving these things different names? RjS _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 21 16:56:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGmc-0000WY-K2; Mon, 21 Aug 2006 16:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGmb-0000TN-MB for sip@ietf.org; Mon, 21 Aug 2006 16:54:05 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFGma-0006wb-76 for sip@ietf.org; Mon, 21 Aug 2006 16:54:05 -0400 Received: (qmail 511 invoked by uid 0); 21 Aug 2006 20:53:42 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 21 Aug 2006 20:53:42 -0000 Message-ID: <000601c6c563$e6e94800$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Vijay K. Gurbani" , "SIP LIST" References: <44EA0891.6080909@lucent.com> Subject: Re: [Sip] Updated revision of connect-reuse(draft-ietf-sip-connect-reuse-06) Date: Mon, 21 Aug 2006 22:53:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay, Regarding virtual servers - it is not that an instant message would end up in the wrong mailbox, but a secure connection for domain X would get reused as a connection to domain Y. This has been called "totally broken" by Cullen 1) I wonder, how broken is it really? Could there be cases where the virtual domain operator may decide to allow this (ie local policy)? Couldn't it be 'SHOULD' strength? 2) Since TCP does not provide much security anyway, is there really harm in sharing TCP connections across virtual domains? Regards, Jeroen ----- Original Message ----- From: "Vijay K. Gurbani" To: "SIP LIST" Sent: Monday, August 21, 2006 9:25 PM Subject: [Sip] Updated revision of connect-reuse(draft-ietf-sip-connect-reuse-06) > Folks: > > On behalf of my co-authors, I have just submitted the latest > revision (-06) to draft-ietf-sip-connect-reuse. > > This version should (hopefully) get the draft out of the WGLC > state. It addresses the concerns and comments raised during > the WGLC period, including support for name-based virtual > servers across TCP and TLS. The text has been also redone for > readability. More attention is paid to TCP connection reuse > than was the case with the previous versions. > > Until the archive is updated with the new version, you can get > a copy from: > > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-06.html > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-06.txt > > Please go through the draft and advise regarding comments you > may have. > > As the co-author holding the editor's pen, I believe that the > draft is ready to proceed further. I will wait to hear from > the chairs about the next steps for this particular document. > > Thank you. > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Bell Laboratories, Lucent Technologies, Inc. > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 21 17:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGtP-0002oJ-5t; Mon, 21 Aug 2006 17:01:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGtN-0002k0-3f for sip@ietf.org; Mon, 21 Aug 2006 17:01:05 -0400 Received: from [2001:5c0:8fff:fffe::4c3d] (helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFGtK-0000RG-U9 for sip@ietf.org; Mon, 21 Aug 2006 17:01:05 -0400 Received: from [192.168.0.106] (pool-71-164-175-25.dllstx.fios.verizon.net [71.164.175.25]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k7LL0hjW004869 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 21 Aug 2006 16:00:49 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Mon, 21 Aug 2006 16:00:41 -0500 To: IETF SIP List X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sip-chairs@tools.ietf.org Subject: [Sip] GRUU-10: Storing state at the binding-agent (GRUU-factory?) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org gruu-10 has a mixed message about the requirements on the overall system for saving information about the existence of GRUUs. It notes on page 13 that * "for any particular AOR, there can be a potentially infinite number of GRUUs" and goes on to say *"it is RECOMMENDED that a GRUU be created at the time a contact with an instance ID is first registered to an AOR (even if that registration indicates that the registering UA doesn't even support GRUUs) This section implies that new state is created at the thing that "owns" GRUUs for each new GRUU that gets created, and recognizes that _clients_ can ask that thing to create an infinite number of them. Later in that section it talks about the difficulty of maintaining this state across reboots and power-failures. A little later (page 15) it notes again that a UA MUST be prepared to receive a different GRUU for the same instance-id/AoR pair in subsequent registrations because this owning-thing might lose state. But, off in the appendix, in sections describing the creation of GRUUs it talks about building them such that this owning-thing doesn't have to create new state. Is there a real requirement to keep state here or not? I don't think we meant there to be in the end, and that some of the text is legacy and just needs to be elided or adjusted, but I can't tell for sure, so let me ask the question another way: Is it OK for me as a proxy that has the responsibility for retargeting GRUUs to _always_ return a 480 to a GRUU that I recognize as feasibly mine (cryptographically perhaps), maps correctly (whatever that means) to an AoR in good standing, but has no current registered contact associated with it EVEN IF I have no record of dealing with that particular instance-id ever before? I think it is. Furthermore, I suspect would be an error to return, say, a 404 in the circumstance above - if I'm wrong, then we need text that reinforces that a 404 to a GRUU doesn't say a thing about the existence or viability of an AoR that might be derivable from that GRUU. Same with 410. So if the intent is not to require infinite state storage, can we tune that language out? (If it was the intent, then we've got other text discussing those ramifications that needs to go in). RjS _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 21 17:47:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFHYk-0000ig-TN; Mon, 21 Aug 2006 17:43:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFHYi-0000iZ-Re for sip@ietf.org; Mon, 21 Aug 2006 17:43:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFHYg-0005Hj-9h for sip@ietf.org; Mon, 21 Aug 2006 17:43:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Aug 2006 14:43:43 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,153,1154934000"; d="scan'208"; a="37291802:sNHT24658730" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7LLhhdo027113; Mon, 21 Aug 2006 17:43:43 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7LLhgdM015526; Mon, 21 Aug 2006 17:43:42 -0400 (EDT) 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); Mon, 21 Aug 2006 17:43:42 -0400 Received: from [10.86.242.53] ([10.86.242.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 17:43:40 -0400 Message-ID: <44EA290B.9070401@cisco.com> Date: Mon, 21 Aug 2006 17:43:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] GRUU-10: Storing state at the binding-agent (GRUU-factory?) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 21:43:40.0332 (UTC) FILETIME=[DDB2B6C0:01C6C56A] DKIM-Signature: a=rsa-sha1; q=dns; l=4053; t=1156196623; x=1157060623; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20GRUU-10=3A=20Storing=20state=20at=20the=20binding-agent= 20(GRUU-factory?) |To:Robert=20Sparks=20; X=v=3Dcisco.com=3B=20h=3DLThu3K1/OW/MjGuxWIq3+aheS/I=3D; b=Ul8sl9PyafTVQTqx0vQb1gUpqvRwn+U1NOmgJ/uOvfWTKzAsbSeH5RyKhNmkDz6MlvahyVdk 3pfIduYb8VVL1vA6QFxSUZODKSr7pj/ujLaba0Gpqo0Vwh/a9Dws5dA5; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: IETF SIP List , sip-chairs@tools.ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Robert Sparks wrote: > gruu-10 has a mixed message about the requirements on the overall system > for saving information about the existence of GRUUs. > > It notes on page 13 that > * "for any particular AOR, there can be a potentially infinite number of > GRUUs" > and goes on to say > *"it is RECOMMENDED that a GRUU be created at the time a contact with an > instance ID is first registered to an AOR (even if that registration > indicates that the registering UA doesn't even support GRUUs) > > This section implies that new state is created at the thing that "owns" > GRUUs for each new GRUU that gets created, and recognizes that _clients_ > can ask that thing to create an infinite number of them. Later in that > section it talks about the difficulty of maintaining this state across > reboots and power-failures. > > A little later (page 15) it notes again that a UA MUST be prepared to > receive a different GRUU for the same instance-id/AoR pair in subsequent > registrations because this owning-thing might lose state. > > But, off in the appendix, in sections describing the creation of GRUUs > it talks about building them such that this owning-thing doesn't have to > create new state. > > Is there a real requirement to keep state here or not? My interpretation of this is: - there are ways to implement gruu that do not require the keeping of state. A registrar may use such a technique if it wishes. - there are other ways of implementing gruu that would require the keeping of state. A registrar may use such a technique if it wishes. If so, then there are some requirements and some recommendations about when, how, and for how long that state should be kept. In general it must be kept as long as a registration remains valid, and it should be kept longer, preferably as long as the AOR remains valid. > I don't think we meant there to be in the end, and that some of the text > is legacy and just needs to be elided or adjusted, but I can't tell for > sure, so let me ask the question another way: > > Is it OK for me as a proxy that has the responsibility for retargeting > GRUUs to _always_ return a 480 to a GRUU that I recognize as feasibly > mine (cryptographically perhaps), maps correctly (whatever that means) > to an AoR in good standing, but has no current registered contact > associated with it EVEN IF I have no record of dealing with that > particular instance-id ever before? > > I think it is. Yes, I think so too. > Furthermore, I suspect would be an error to return, say, a 404 in the > circumstance above - I agree. > if I'm wrong, then we need text that reinforces > that a 404 to a GRUU doesn't say a thing about the existence or > viability of an AoR that might be derivable from that GRUU. Same with 410. > > So if the intent is not to require infinite state storage, can we tune > that language out? As above, I think it is there for the case of a registrar that doesn't want to embed everything in the gruu. There could be reasons for that, so I think it is fair to allow it and to spell out the implications of doing so. But maybe this could be made clearer. I spent some time trying to figure out how to do anonymous gruus. After banging my head for awhile I decided to put it off till later. But I expect that being stateful may be part of the solution to that. It may be ok in that case, because it seems that it doesn't make a lot of sense for anonymous gruus to last a long time. Paul > (If it was the intent, then we've got other text discussing those > ramifications that needs to go in). > > RjS > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 21 18:09:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFHvD-0000o4-Ha; Mon, 21 Aug 2006 18:07:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFHvC-0000nz-FQ for sip@ietf.org; Mon, 21 Aug 2006 18:07:02 -0400 Received: from [2001:5c0:8fff:fffe::4c3d] (helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFHv9-0003Vc-D1 for sip@ietf.org; Mon, 21 Aug 2006 18:07:02 -0400 Received: from [192.168.0.106] (pool-71-164-175-25.dllstx.fios.verizon.net [71.164.175.25]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k7LM6fMP023200 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 21 Aug 2006 17:06:45 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <850EF6C5-45B9-431D-9B81-6FBB4D38EC2F@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Mon, 21 Aug 2006 17:06:39 -0500 To: IETF SIP List X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip-chairs@tools.ietf.org Subject: [Sip] GRUU-10: in-vs-out-of-dialog gruu retargetting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I forced myself (1) to forget the various conversations we had around last-hop-spiraling and the interaction of GRUU with outbound and tried to read the proxy behavior section from the point-of-view of an implementer who didn't have the list/meeting history in their head. With those preconditions 8.2.1 through 8.2.3 get somewhat confusing. First - It's not clear why there's any distinction between in-dialog and out-of-dialog requests in the first place. That distinction isn't normal for a proxy - what's special that makes it normal here? Next, if it is necessary to distinguish them, the criteria currently in the draft won't work. You can have out-of-dialog requests show up with Route headers fields. The only difference in behavior that I can back out of the current text (did I miss something?) is dealing with the situation where there is more than one contact currently bound to the GRUU. 8.2.1 says to use the most recent, 8.2.3 says to pick arbitrarily. To the implementer, this is going to appear arcane at best. Do we really _need_ the distinction? Can we not reduce the whole of section 8.2 down to one or two paragraphs by unifying those sections? (3261 asks you to record-route mid-dialog requests anyhow, so we should be able to roll the 8.2.2 in at the same time). RjS (1) Well, I didn't really have to use much force in order to forget _that_ stuff. :O _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 21 18:53:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFIb8-00074x-45; Mon, 21 Aug 2006 18:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFIaq-0006t0-8N; Mon, 21 Aug 2006 18:50:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFIap-0002QJ-Vs; Mon, 21 Aug 2006 18:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 0641C3288D; Mon, 21 Aug 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GFIan-0002k1-T7; Mon, 21 Aug 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 21 Aug 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy, et al. Filename : draft-ietf-sip-connect-reuse-06.txt Pages : 21 Date : 2006-8-21 When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency in environments where the connection could be opened in either direction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-connect-reuse-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-connect-reuse-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-21163714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connect-reuse-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-21163714.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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-- From sip-bounces@ietf.org Mon Aug 21 20:02:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFJfT-0000xe-W5; Mon, 21 Aug 2006 19:58:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFJfT-0000xX-22 for sip@ietf.org; Mon, 21 Aug 2006 19:58:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFHVG-0004MY-2b for sip@ietf.org; Mon, 21 Aug 2006 17:40:14 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFHLg-0003Ml-U1 for sip@ietf.org; Mon, 21 Aug 2006 17:30:22 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 21 Aug 2006 14:29:52 -0700 X-IronPort-AV: i="4.08,153,1154934000"; d="scan'208"; a="1849423886:sNHT2208062970" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7LLTqTq013660; Mon, 21 Aug 2006 14:29:52 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7LLTp6Y015163; Mon, 21 Aug 2006 14:29:52 -0700 (PDT) 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); Mon, 21 Aug 2006 17:29:51 -0400 Received: from [10.86.242.53] ([10.86.242.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 17:29:49 -0400 Message-ID: <44EA25CD.20709@cisco.com> Date: Mon, 21 Aug 2006 17:29:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] GRUU-10: "gruu" as both a header and URI parameter References: <2B87277A-D19C-43D2-987B-C8DEA01456D2@estacado.net> In-Reply-To: <2B87277A-D19C-43D2-987B-C8DEA01456D2@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 21:29:49.0976 (UTC) FILETIME=[EEC47180:01C6C568] DKIM-Signature: a=rsa-sha1; q=dns; l=1569; t=1156195792; x=1157059792; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20GRUU-10=3A=20=22gruu=22=20as=20both=20a=20header=20and=2 0URI=20parameter; X=v=3Dcisco.com=3B=20h=3DGTp08moAU4voNgkG31Rkubc39LE=3D; b=itpd65/7cptf9C8l0x6Q85x4ymlyuMUOGJweJNFzYX9Q+MUoMcmSEh8tuqjAqPooqrMA1uCg EheQrJbw+qIsF7gi0K8o7UB4+Nn686niwDbKs/Ax2nrZxbK1l8nyFWL+; Authentication-Results: sj-dkim-7.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: IETF SIP List , sip-chairs@tools.ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org How about "gruu" and "GRUU"? :-) Actually, in this case it doesn't bother me enough to want to change it. But I won't fight against a change. Paul Robert Sparks wrote: > I've got several comments for the gruu spec for today's deadline, and > will meet Keith's formatting requirement for them in > other messages. There are a couple of topics I wanted to start > individual threads on though. Here's the first: > > Right now, the mechanism is creating a header parameter and a URI > parameter with the same name : "gruu". > > Thinking about this from the perspective of debugging things in a lab, > or worse, over VoIP or an IM, I envision > many, many conversations that will take this form: > > A: I see the problem - it's in the gruu parameter. > B: Ok - I'll change that > (retry) > A: It's still broken - I don't see what you... Oh wait - I didn't mean > _that_ gruu parameter, go > change the other one. > B: Oh crud - was it the header parameter or the URI parameter? (and > which one of those is outside > the <>'s? I can never keep that straight...) > > For the sake of sanity (at least mine), could we please reconsider > giving these things different names? > > RjS > > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Mon Aug 21 22:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFMA8-00079d-Uu; Mon, 21 Aug 2006 22:38:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFMA7-00073g-2E for sip@ietf.org; Mon, 21 Aug 2006 22:38:43 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFLx1-0000Ig-Jv for sip@ietf.org; Mon, 21 Aug 2006 22:25:12 -0400 Received: from [192.168.2.106] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7M2RNSu009152 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 21 Aug 2006 21:27:23 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 21 Aug 2006 21:24:57 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF SIP List , sip-chairs@tools.ietf.org Subject: [Sip] Re: GRUU-10: Storing state at the binding-agent (GRUU-factory?) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 21, 2006, at 4:00 PM, Robert Sparks wrote: > > Furthermore, I suspect would be an error to return, say, a 404 in > the circumstance above - if I'm wrong, then we need text that > reinforces that a 404 to a GRUU doesn't say a thing about the > existence or viability of an AoR that might be derivable from that > GRUU. Same with 410. > This is where I think GRUU is wrapped around the axle. In my world view, a GRUU is just a synthetic or aliased Contact. If we could have a "route vector" instead of a Contact, we wouldn't need GRUU (except for the anonymization part, which is IMHO bogus). What happens when you send an request through a proxy to a Contact that no longer exists? Why would this say anything about the AOR, other than that the contact is stale? Why should it be different for a GRUU? -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 21 22:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFMJW-0002Ck-93; Mon, 21 Aug 2006 22:48:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFMJV-0002Cf-7f for sip@ietf.org; Mon, 21 Aug 2006 22:48:25 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFMJU-0005v0-FX for sip@ietf.org; Mon, 21 Aug 2006 22:48:25 -0400 Received: from [192.168.0.106] (pool-71-164-175-25.dllstx.fios.verizon.net [71.164.175.25]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k7M2l40g023017 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 21 Aug 2006 21:47:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <939B827E-F7D3-4D58-A9F2-92E879A0DAB2@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Mon, 21 Aug 2006 21:47:02 -0500 To: IETF SIP List X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 71.164.175.25 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Cc: sip-chairs@tools.ietf.org Subject: [Sip] gruu-10 focused review comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org These are my review comments in the form requested by Keith. Summary: I believe this document to be technically correct, modulo the questions that I brought to the list separately. I also believe it reflects WG discussions to date. However, it appears to me to still be in the "result of lots of arguing about little things" stage from a clarity point of view and would benefit greatly from another strong editorial revision (I think most non-IETF-attending implementors will give up reading before completing the current document). General comments: I have, since this whole idea got traction, felt discomfort with what this extension will do to the architecture of future systems if it is not applied with reason. The simple lazy "well, lets just always use a GRUU because then it will always work" approach leads to a world where there is _NEVER_ a SIP transaction that doesn't involve a "service provider" (I really had to fight with myself to not write gatekeeper just then). This consequence is lightly explored on page 19 - I would like it to see it under a much brighter spotlight, and I would like to see some guidance that would prevent unnecessary GRUU proliferation. Don't take this as a desire to not have GRUUs - I do agree that we need them for UAs that can't otherwise be reached. I just don't want to put out the firemen while putting out the fire. There is a lot of text that reduces to "If you implement that extension over there, do what that extension tells you what to do". It was important during development of the text to make sure we worked in the context of those extensions, but having completed that exercise, I think we can safely elide the text (or reduce it to one standalone section). (outbound was bugging us at the time, so there's a bunch of outbound text here that doesn't really belong - we don't have, for instance, discussion of 183 using 100rel everywhere it might make sense) There are some concepts that this document seems to create, but doesn't formally define or borrow some other formal definition. The one that bugs me the most is "home proxy". I got really lost during a linear read-through on what the requirements around including opaque, and instance ID were, especially when it came to being able to remove them and infer things from the result. After digging at it, I think the document is internally consistent (but don't feel 100% confident there). It would be very good to condense these into one authoritative set of statements. I have not attempted to be comprehensive with grammar nits in the comments below - I captured things as I spotted them, but I hope we'll be doing a nit review of a revision and saved that level of effort for that time. Those I captured, I'll send to Jonathan directly. --- Location: Section 5 2nd paragraph Nature: editorial Suggested fix: This extension defines two separate mechanisms. The first provides one way for a UA to obtain a GRUU. The second allows a UA to use a GRUU, regardless of how it obtained it. This extension defines the protocol operations for obtaining GRUUs through registration, and discusses the alternative of obtaining GRUUs through administrative operation. --- Location: Section 5 3rd paragraph, last sentence Nature: minor technical Suggested fix: OLD: instance identifier, the server NEW: instance identifier against the same AoR, the server --- Location: Section 5 7th paragraph (first full text paragraph on page 9) Nature: editorial Comment: The first sentence (containing "it would set the value") will be taken as normative by the implement-the-examples crowd. This sentence is true only for one of the suggestions for forming opaque. Suggested fix: change "would set" to "might set" --- Location: Section 5 8th paragraph, last sentence Nature: editorial Comment: For the first time reader, the consequence described in the last sentence is not yet obvious. Suggested fix: replace the last sentence with "This allows the UA to tell that the request was originally sent to a GRUU with no grid instead of to an AOR". --- Location: Section 6 first paragraph on page 10. Nature: minor technical Comment: the instance identifier uniquely identifies the agent amongst all other user agents (full stop). Suggested fix: delete "associated with an AOR" --- Location: Section 6 second paragraph on page 10 Nature: editorial Comment: I think the diagram covers this paragraph sufficiently and suggest either deleting the paragraph or starting it off with something along the lines of "this paragraph describes the figure 3 in text form". --- Location: Section 6 second paragrpah (starting "The contacts that are bound") Nature: editorial Comment: The important message here (the last two sentences) gets lost under the wieght of the first part of the paragraph. That first part loses me completely, so I'm having a hard time suggesting alternative text. Would anything be lost if it were deleted? --- Location: Section 6, page 11 second bullet. Nature: minor technical Comment: As you point out elsewhere, the thing that is responsible for resolving the GRUU may not actually be a proxy. Suggested fix: delete proxy from the last sentence in this bullet (leaving "route to a server with access" --- Location: Section 6, page 12 first paragraph (Starting "Section 8.2") Nature: editorial Comment: This section is about the creation of GRUUs - this sentence doesn't belong here. Suggested fix: Delete the sentence --- Location: Section 6, page 12, paragraphs 2 through 5 (starting with "When a domain constructs") Nature: editorial Comment: The first of these paragraphs is a no-op and can safely go away. The second and third are all about _USING_ GRUUs, not forming them and doesn't belong in this section. Thier content is covered elsewhere. Recommendation: Delete these three paragraphs --- Location: Section 6, page 12, last full paragraph (starting with "Mid- dialog requests), last sentence Nature: minor(ish) technical Comment: You can get URIs into Route headers of initial requests. There is the possibility that this URI would be the same as what you might have record-routed with if this were a mid-dialog request. Using Route to distinguish initial requests from mid-dialog requests is not safe as specified here. Given that things like "screening services" are not well defined, I am very nervous about putting normative text around their invokation. It's still very unclear to me that you would ever want to do something different with a GRUU at a proxy if you encountered it in or outside a dialog. If there's a feature that relies on this knowledge, that feature should be asking the UA to participate in giving the featuure-server the information it needs to not do the wrong thing. Suggested fix: Reduce the strength of the text exploring different services to descriptive. Remove the in-vs-out of dialog distinction text. --- Location: Section 6, last paragraph Nature: technical Comment: Raised in a separate thread (infinite state storage) --- Location: Section 7, top of page 14, first fractional sentence Nature: editorial Comment/Suggested Fix: Can we put a pointer to wherever we have guidance on how to form these instance ID values at the end of this sentence? --- Location: Section 7, 1st full paragraph page 14 Nature: technical Comment: This RECOMMENDED almost has a "why this isn't must", but it's not quite all there. Why isn't it a MUST? Is it because UAs can do this differentiation in other ways (I'm not sure I see one), or is it that there are some UAs that won't care? --- Location : Section 7, 2nd full paragraph - page 14 (If a UA instance is trying to register multiple contacts...) Nature editorial/technical Comment: Can we scope this paragraph to GRUUs or delete it? This feels like a very odd general requirement. Even scoped to GRUUs this feels like an inappropriate MUST. Advisory text along the lines of "GRUUs are not intended to provide redundancy through the use of multiple contacts. Implementations seeking that functionality should utilize the mechanisms in [11] instead." would be better. --- Location: Section 7, third full paragraph page 14. Nature editorial/technical Comment: For the last two sentences, which are attempting to avoid GRUU loops, it's not clear if this is a place where the contact violates the SHOULD NOT above it with respect to not containing the "gruu" header field (or is it URI) parameter, or if this is a contact that has no instance-id, gruu, or grid parameters but is still (somehow) a GRUU? --- Location: Section 7, fourth full paragraph page 14. Nature: editorial Comment: This doesn't appear to add anything that we don't already say or get from 3261. Suggest striking it. --- Location: Section 7, 5th full paragraph page 14 (starting "If a UA wishes to guarantee") Nature: minor technical Suggested fix: OLD: guarantee that the request is not processed NEW: guarantee that the REGISTER request is not processed --- Location: Section 7, 5th full paragraph page 14 (starting "If a UA wishes to guarantee") Nature: editorial Suggested fix: OLD: option tag. This is in addition to the presence of the Supported header field. NEW: option tag, in addition to a Supported header field also containing the "gruu" option tag. --- Location: Section 7.1.1.2 first paragraph Nature: editorial Comment: This whole paragraph is subjugate to the if in the next paragraph. Suggest restructuring it so everythings under one IF clause. --- Location: Section 7.1.1.2 first paragraph Nature: editorial Comment: Its not clear what "extract the contacts" means here --- Location: Section 7.1.1.2 page 15 first paragraph Nature: editorial Comment Can we pull the SIP/SIPS behaviors out into one paragraph standing on its own in the document? It should be a simple one. As it stands, my head was swimming after the sentence in this paragraph enough that I couldn't track the next idea. --- Location: Section 7.1.1.2 page 15 first paragraph somewhere near the middle (look for "domain to a contact with" at the start of a line Nature: minor technical Comment/fix: Suggest changing to "domain to the contact with" --- Location: Section 7.1.1.2 page 15, last paragraph before 7.1.2 Nature: technical Comment: This paragraph implies that you _can_ remove, delete, or otherwise invalidate a GRUU through some mechanism. What is it? As far as I can tell, it's ONLY through the administrative removal of the AoR. I think this paragraph may have meant to be talking about the contacts that might be bound to the GRUU, not the GRUU itself. Suggested fix: Change this paragraph to explicitly talk about the contacts bound to the GRUU. Add a paragraph noting that GRUUs are never deleted through the mechanisms in this document - that they only go away through administrative removal of the AoR they are associated with. --- Location: Section 7.1.2 second paragraph. Nature: editorial Comment: This will be read to say there are THREE URIs, the GRUU and the SIP and SIPS versions of the GRUU. Suggested fix. Remove all the SIP/SIPS treatment to its own section, avoid this particular sentence construct in that section. --- Location: Section 7.1.2.1 first paragraph Nature: minor technical Comment/fix: add "containing the 'gruu' feature tag" after "might contain a Require header field:. --- Location: Section 7.1.2.1 top paragraph on page 16 Nature: technical/editorial Comment: This says to create a GRUU according to the procedures of Section 6, but there are no procedures in section 6, only characteristics, a statement that the process of creation is implementation dependent, and pointers to the appendix for how one might go about such creation. Suggested fix: s/proceedures/requirements/ --- Location: Section 7.1.2.1 top paragraph on page 16 Nature: editorial Comment: The pronouns in this paragraph are ambiguous. "it MUST be ignored", "they MUST be discarded" Suggested fix: use the nouns --- Location: Section 7.1.2.1 first paragraph, last sentence Nature: confused Comment: This sentence says contacts omitting the instance parameter are not processed by the rules in this specification, but back on page 14, you talk about registering GRUUs as contacts but leaving of the instance id. Is that that resulting thing a GRUU or not? Either this paragraph or the third full paragraph on page 14 needs clarification. --- Location: Section 7.1.2.1 third paragraph page 16 Nature: minor technical Comment: Why does the registrar put the instance id in the contact header field if the request didn't contain Supported: gruu? A registrar that doesn't know gruu isn't going to do this. A UA that doesn't know GRUU or outbound isn't going to use it? This looks like a setup for a subtle interop problem later. ---- Location: Section 7.1.2.1 fourth paragraph last sentence Nature: editorial/minor technical Comment/fix: change the end of the last sentence from "a GRUU" to "any GRUU that is bound to that AoR". --- Location: Section 7.1.2.1 (no specific place) Nature: minor technical Comment; It would be useful to point out somewhere that this specification SPECIFICALLY doesn't allow a contact to be bound into the system that will be reached when the GRUU is accessed, but not reached when the AOR is accessed. --- Location: Section 7.1.2.1 last paragraph Nature: minor technical Comment: This looks like normative requirements (MUST NOTs?) in disguise. --- Location: Section 7.2 4th paragraph last sentence Nature: editorial/technical Comment: This requirement is very undermotivated. Why must I include the gruu parameter here. Who's going to care and do anything different with it? Normally it would be the thing resolving the GRUU, but in this case, THAT'S ME, not some other proxy. Why are we trying to put requirements on how I talk to myself? --- Location: Section 8.1.1 first paragraph Nature: editorial Comment: as written, there will be some implementer that won't let you use a third-party gruu (one obtained through a REFER for example) because you don't have an active registration for it. Suggested fix: Put a paragraph break after the first sentence. Replace the second sentence with "A UA MUST NOT use a GRUU it obtained through registration unless that registration is still active." --- Location: Section 8.1.1 second paragraph Nature: editorial Comment: When would an implementation consider violating this SHOULD? We should document this (see my architectural concern at the beginning) or make this a MUST and be done with it. --- Location: Section 8 (generally) Nature: editorial Comment: (from the beginning) "home proxy" starts to creep in here --- Location: Section 8.1.1. last paragraph page 18 (first on page 19) Nature: editorial Comment: I can't parse much of this - the sentence on using service route in particular eludes me. Suggested fix: I don't have one yet - will keep trying to make this make sense. --- Location: Section 8.1.1 last paragraph page 19 Nature: editorial Comment/fix: change "in requests it generates" to "in all requests it generates" --- Location : Section 8.1.2 2nd and third paragraphs Nature: editorial Comment: What does any of this have to do with Sending a message to a GRUU (the section title) Suggested fix: Create a new section for these two paragraphs "Sending a request to an AOR derived from a GRUU" --- Location 8.2.1, 8.2.2 8.2.3 Nature: editorial/technical Comment; (See thread on whether we really need to separate in-vs-out- of-dialog --- Location: Security considerations Nature: minor technical Comment: We talk about how there is no privacy coming from a GRUU and how we can guess instance-ids or repeated instance-ids with against a given AoR, but I don't think we talk about hotelling. If you know the last person that used a particular device (because you knew they were in a cube or a hotel room) and you watched the instance-id they used, then if you know the next person using that device, you can guess a gruu for them. Does that do you any good? Imagine you were traveling and were letting your assistant (we all have those, right) answer your calls, but you'd grab them if it rang more than twice... _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 01:49:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFP5R-0002En-3E; Tue, 22 Aug 2006 01:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFP5O-0002Ef-O1 for sip@ietf.org; Tue, 22 Aug 2006 01:46:02 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFP5M-0005kM-Ee for sip@ietf.org; Tue, 22 Aug 2006 01:46:02 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 21 Aug 2006 22:46:00 -0700 X-IronPort-AV: i="4.08,154,1154934000"; d="scan'208"; a="1849522378:sNHT32602916" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7M5jxoW032720; Mon, 21 Aug 2006 22:45:59 -0700 Received: from [192.168.1.3] (sjc-vpn7-596.cisco.com [10.21.146.84]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7M5jx6W006840; Mon, 21 Aug 2006 22:45:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <2B87277A-D19C-43D2-987B-C8DEA01456D2@estacado.net> References: <2B87277A-D19C-43D2-987B-C8DEA01456D2@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44C94B32-8591-47F6-A6FB-7D8D2C92ED83@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] GRUU-10: "gruu" as both a header and URI parameter Date: Mon, 21 Aug 2006 22:45:54 -0700 To: Robert Sparks , IETF SIP List X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1176; t=1156225559; x=1157089559; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20GRUU-10=3A=20=22gruu=22=20as=20both=20a=20header=20and=2 0URI=20parameter; X=v=3Dcisco.com=3B=20h=3DTAQNpPYaGZ8u4RgNHkjIcB7l/MU=3D; b=B56W3STSVOTAIT2FsDnqqAMTDDGZo+DxptxSo4UHPwcpvLezd++0nRVtm2hkFZaRI5zHR1ur 3GUX9tbRLIpOQJOl7gdgY8l1DOk+3GlW64Qpv7ryTonS94D4xrpE6xU7; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 21, 2006, at 1:26 PM, Robert Sparks wrote: > Right now, the mechanism is creating a header parameter and a URI > parameter with the same name : "gruu". > > Thinking about this from the perspective of debugging things in a > lab, or worse, over VoIP or an IM, I envision > many, many conversations that will take this form: > > A: I see the problem - it's in the gruu parameter. > B: Ok - I'll change that > (retry) > A: It's still broken - I don't see what you... Oh wait - I didn't > mean _that_ gruu parameter, go > change the other one. > B: Oh crud - was it the header parameter or the URI parameter? (and > which one of those is outside > the <>'s? I can never keep that straight...) > > For the sake of sanity (at least mine), could we please reconsider > giving these things different names? Add my plea for consideration to Robert's - implementors are confused enough about the difference between header parameters and uri parameters without us adding to the confusion. It's not like gruu is such an intuitively descriptive acronym that nothing else could make sense, we could have gruu and groovy :-) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 01:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFPE7-0004iv-3w; Tue, 22 Aug 2006 01:55:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFPE5-0004il-KD for sip@ietf.org; Tue, 22 Aug 2006 01:55:01 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFPE4-0007yE-Ba for sip@ietf.org; Tue, 22 Aug 2006 01:55:01 -0400 Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k7M5smDd005217; Tue, 22 Aug 2006 01:54:48 -0400 Received: from SONUSINMAIL01.sonusnet.com ([10.128.254.7]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 01:54:48 -0400 content-class: urn:content-classes:message Subject: RE: [Sip] GRUU-10: "gruu" as both a header and URI parameter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Aug 2006 11:24:44 +0530 x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: <70798CF421F00F4DA018059E5B7EEB8C7A63FC@sonusinmail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU-10: "gruu" as both a header and URI parameter Thread-Index: AcbFfkwYbnI/JSk/R/K0gka244hjSwAMNwUw From: "B, Nataraju" To: "Paul Kyzivat" , "Robert Sparks" X-OriginalArrivalTime: 22 Aug 2006 05:54:48.0665 (UTC) FILETIME=[7A317C90:01C6C5AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: IETF SIP List , sip-chairs@tools.ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comments inline... Thanks, Nataraju A B > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, August 22, 2006 3:00 AM > To: Robert Sparks > Cc: IETF SIP List; sip-chairs@tools.ietf.org > Subject: Re: [Sip] GRUU-10: "gruu" as both a header and URI parameter >=20 > How about "gruu" and "GRUU"? :-) >=20 > Actually, in this case it doesn't bother me enough to want to change it. > But I won't fight against a change. >=20 [ABN] even if think of doing this, it would add lot of deviation when compared to other header/URI parameters.=20 In most of the cases all the parameters have been considered case-insensitive.=20 > Paul >=20 > Robert Sparks wrote: > > I've got several comments for the gruu spec for today's deadline, and > > will meet Keith's formatting requirement for them in > > other messages. There are a couple of topics I wanted to start > > individual threads on though. Here's the first: > > > > Right now, the mechanism is creating a header parameter and a URI > > parameter with the same name : "gruu". > > > > Thinking about this from the perspective of debugging things in a lab, > > or worse, over VoIP or an IM, I envision > > many, many conversations that will take this form: > > > > A: I see the problem - it's in the gruu parameter. > > B: Ok - I'll change that > > (retry) > > A: It's still broken - I don't see what you... Oh wait - I didn't mean > > _that_ gruu parameter, go > > change the other one. > > B: Oh crud - was it the header parameter or the URI parameter? (and > > which one of those is outside > > the <>'s? I can never keep that straight...) > > > > For the sake of sanity (at least mine), could we please reconsider > > giving these things different names? > > > > RjS > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 22 02:00:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFPHN-00072p-8n; Tue, 22 Aug 2006 01:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFPHL-0006vt-P1 for sip@ietf.org; Tue, 22 Aug 2006 01:58:23 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFPHI-0000ID-Fj for sip@ietf.org; Tue, 22 Aug 2006 01:58:23 -0400 Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k7M5w9oC006604; Tue, 22 Aug 2006 01:58:09 -0400 Received: from SONUSINMAIL01.sonusnet.com ([10.128.254.7]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 01:58:09 -0400 content-class: urn:content-classes:message Subject: RE: [Sip] GRUU-10: "gruu" as both a header and URI parameter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Aug 2006 11:28:05 +0530 x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: <70798CF421F00F4DA018059E5B7EEB8C7A6403@sonusinmail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU-10: "gruu" as both a header and URI parameter Thread-Index: AcbFrqMYFwQpBaKoSaOkbk22Zd8n0wAAO1MA From: "B, Nataraju" To: "Cullen Jennings" , "Robert Sparks" , "IETF SIP List" X-OriginalArrivalTime: 22 Aug 2006 05:58:09.0497 (UTC) FILETIME=[F1E60490:01C6C5AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If we mandate for gruu as a URI parameter, I mean within ANGLE brackets '< >' would solve all the problems, I guess so.=20 Thanks, Nataraju A B > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, August 22, 2006 11:16 AM > To: Robert Sparks; IETF SIP List > Subject: Re: [Sip] GRUU-10: "gruu" as both a header and URI parameter >=20 >=20 > On Aug 21, 2006, at 1:26 PM, Robert Sparks wrote: >=20 > > Right now, the mechanism is creating a header parameter and a URI > > parameter with the same name : "gruu". > > > > Thinking about this from the perspective of debugging things in a > > lab, or worse, over VoIP or an IM, I envision > > many, many conversations that will take this form: > > > > A: I see the problem - it's in the gruu parameter. > > B: Ok - I'll change that > > (retry) > > A: It's still broken - I don't see what you... Oh wait - I didn't > > mean _that_ gruu parameter, go > > change the other one. > > B: Oh crud - was it the header parameter or the URI parameter? (and > > which one of those is outside > > the <>'s? I can never keep that straight...) > > > > For the sake of sanity (at least mine), could we please reconsider > > giving these things different names? >=20 > Add my plea for consideration to Robert's - implementors are confused > enough about the difference between header parameters and uri > parameters without us adding to the confusion. >=20 > It's not like gruu is such an intuitively descriptive acronym that > nothing else could make sense, we could have gruu and groovy :-) >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 22 04:20:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFRRc-0004rD-NR; Tue, 22 Aug 2006 04:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFRRa-0004r6-R9 for sip@ietf.org; Tue, 22 Aug 2006 04:17:06 -0400 Received: from wp045.webpack.hosteurope.de ([80.237.132.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFRRZ-0004HH-Ik for sip@ietf.org; Tue, 22 Aug 2006 04:17:06 -0400 Received: by wp045.webpack.hosteurope.de running Exim 4.43 using esmtpa from p5481e523.dip.t-dialin.net ([84.129.229.35] helo=zapsamsung) id 1GFRRY-00012g-OE; Tue, 22 Aug 2006 10:17:05 +0200 From: "Sebastian Szczygiel" To: Date: Tue, 22 Aug 2006 10:16:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbFw1SO1fGgdN31Ro2wamP9+jy/Vg== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] SIP - register before send/receive? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Message-Id: Hello, I'm using SIP on Nokia mobile phones in Java... Do you i have to register every time a user before sending or receiving any messages? >From the nokia SIP examples i still haven't understood how receiving works. Seems like all examples are listening on a port for all messages and not only message which are addressed to the user with should receive them. I understand that sip:*;type=\"application/test\" means for me, that the SipServer-Listener-implementation is listening for all messages which belong to the application 'test'. Ok, let's say i have several users and i don't want all messages but only the message which belong to me. How do i realize that? How do I let the sip server know that I'm user "user2" and want only messages from "user1". BR, Sebastian _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 07:13:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFU7y-0006Sa-H1; Tue, 22 Aug 2006 07:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFU7w-0006OB-Co for sip@ietf.org; Tue, 22 Aug 2006 07:09:00 -0400 Received: from jes-fe2.zx.nl ([194.187.76.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFU7q-00010l-BA for sip@ietf.org; Tue, 22 Aug 2006 07:08:59 -0400 Received: from Inbox ([84.241.222.136]) by jes-fe2.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J4E00FQ8F9K13A0@jes-fe2.zx.nl> for sip@ietf.org; Tue, 22 Aug 2006 13:13:08 +0100 (WEST) Date: Tue, 22 Aug 2006 13:08:39 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] GRUU-10: "gruu" as both a header and URI parameter To: Paul Kyzivat , Robert Sparks Message-id: <0J4E00FQ9F9L13A0@jes-fe2.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF SIP List , sip-chairs@tools.ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org How about 'gr' for the URI parameter. For "globally routable" Jeroen=20 -----Oorspronkelijk bericht ----- Van: "Paul Kyzivat" Aan: "Robert Sparks" CC: "IETF SIP List" ; sip-chairs@tools.ietf.org Verzonden: 21-8-06 23:29 Onderwerp: Re: [Sip] GRUU-10: "gruu" as both a header and URI parameter How about "gruu" and "GRUU"? :-) Actually, in this case it doesn't bother me enough to want to change it.=20 But I won't fight against a change. Paul Robert Sparks wrote: > I've got several comments for the gruu spec for today's deadline, and=20 > will meet Keith's formatting requirement for them in > other messages. There are a couple of topics I wanted to start=20 > individual threads on though. Here's the first: >=20 > Right now, the mechanism is creating a header parameter and a URI=20 > parameter with the same name : "gruu". >=20 > Thinking about this from the perspective of debugging things in a lab,=20 > or worse, over VoIP or an IM, I envision > many, many conversations that will take this form: >=20 > A: I see the problem - it's in the gruu parameter. > B: Ok - I'll change that > (retry) > A: It's still broken - I don't see what you... Oh wait - I didn't mean=20 > _that_ gruu parameter, go > change the other one. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 14:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbGU-0005Cu-Kp; Tue, 22 Aug 2006 14:46:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbGT-0005Ay-IL for sip@ietf.org; Tue, 22 Aug 2006 14:46:17 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFbGR-0000an-4h for sip@ietf.org; Tue, 22 Aug 2006 14:46:17 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7MIk8i06996; Tue, 22 Aug 2006 14:46:09 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 22 Aug 2006 13:45:38 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DF83FC3@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DEE33C2@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: AcbFNWGcYf0pXNvKRI+1GA5Vf9se5wADijZgADW+z8A= From: "Samir Srivastava" To: "Samir Srivastava" , "Cullen Jennings" , "Joel M. Halpern" X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Regarding 3) Henry made a nice comment on the sipping list in the different context today "("the Internet is THE service") and the user must have choices and control to exercise them. " So from purists' point of view, proxies in middle need to honor the end user wish. Or Am I missing something? Thx Samir > -----Original Message----- > From: Srivastava, Samir (SC100:8826) > Sent: Monday, August 21, 2006 11:02 AM > To: Cullen Jennings; Joel M. Halpern > Cc: SIP > Subject: RE: [Sip] Ciphersuites in SIP >=20 > Hi, >=20 > As AD jumped into, my replies on the comments received so far. >=20 > 1) I am looking into the Dean's comment from the regulatory perspective. > If Regulator's doesn't allow to view the cipher-suite of the earlier hop > to be viewed by the other proxies, then how MTA's are putting that ? Or > they are not complying with this. As the complete message contents are > visible to the next hop proxy, viewing the cipher-suite used at the > earlier hop should not be an issue. It's my hunch only, I have to still > verify it. >=20 > 2) There is cheater proxy case apart from the misconfiguration etc, > which I mentioned in the earlier arguments. It will be useful there. >=20 > 3) I agree that end user doesn't have the contractual agreement with the > providers/proxies in the hops further down. But the security-level > agreement with the end user and his home proxy should be honored by the > middle hops if end-user is particular about the AES256 as of now. >=20 > 4) Jonathan suggested the usage of tool where Periodicity of check is > the bottleneck. Vendors have different way of logging. In the > multi-vendor deployment scenarios with upgrades etc, it will be real > hard to keep this information in sync without leaving a time window of > less secure hops. The other ways of sending the clear text messages by > the proxies can be fixed by configuration etc. But this needs a > mechanism in the protocol, if we agree on the problem definition. >=20 > 5) The proposed solution is extensible to DTLS or any other future > extensions for security protocol, where SIPS in its current definition > of transport parameter is broken. We can add a new parameter > secure-protocol in the URI definition or extend the transport parameter > to TLS+TCP, DTLS+DCCP, DTLS+UDP etc as suggested earlier in the wacky > thread. >=20 > 6) How many S/MIME deployments are there ? >=20 > I will modify the draft with the stress on the problem after having > definitive answer to 1), and see if group has further interest. >=20 > Thx > Samir >=20 > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Friday, August 18, 2006 5:06 PM > > To: Joel M. Halpern > > Cc: Srivastava, Samir (SC100:8826); Jonathan Rosenberg; SIP > > Subject: Re: [Sip] Ciphersuites in SIP > > > > > > On Aug 8, 2006, at 6:48 PM, Joel M. Halpern wrote: > > > > > The proxies don't belong to the end user. Heck, with the way > > > things work in practice, the end user may not even know about the > > > proxies. And very often neither end user has a contractual > > > relationship with the intermediate proxies. > > > > 100% agree. That is why I don't see how you can't provide user > > security using a k,,hop by hop mechanism. If you want user integrity, > > you can get that to some degree with Identity. If you want > > confidentially as well, pretty much S/MIME is the only thing that > > might provide this today. > > > > (And I agree with Dean's chair comment that we need a use case for > > the problem to solve before we get too excited about the solution :-) >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Tue Aug 22 15:15:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbhG-0005su-I6; Tue, 22 Aug 2006 15:13:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbhE-0005so-RG for sip@ietf.org; Tue, 22 Aug 2006 15:13:56 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFbhD-00072N-Hl for sip@ietf.org; Tue, 22 Aug 2006 15:13:56 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 7038F1E8C1C; Tue, 22 Aug 2006 12:13:52 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DF83FC3@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Tue, 22 Aug 2006 12:13:52 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DF83FC3@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Tue, 22 Aug 2006 13:45:38 -0500") Message-ID: <868xlg60sv.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Cullen Jennings , "Joel M. Halpern" , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > Hi, > > Regarding 3) Henry made a nice comment on the sipping list in the > different context today > > "("the Internet is THE service") and the user must have choices and > control to exercise them. " > > So from purists' point of view, proxies in middle need to honor the end > user wish. Or Am I missing something? I think you're missing something. The Internet is a hop-by-hop data switching service. In general, you get a fairly limited amount of control over the treatment that the intermediate switches/routes give your packets provided that they're routing them towards the destination. For instance, there's no way in IP to ask routers not to send your packets over a wireless link. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 15:34:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbyQ-0004uB-UB; Tue, 22 Aug 2006 15:31:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbyP-0004u1-Cm for sip@ietf.org; Tue, 22 Aug 2006 15:31:41 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFbyN-0003KX-2A for sip@ietf.org; Tue, 22 Aug 2006 15:31:41 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7MJVY717245; Tue, 22 Aug 2006 15:31:35 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 22 Aug 2006 14:31:33 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DFEF03E@zrc2hxm2.corp.nortel.com> In-Reply-To: <868xlg60sv.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: AcbGHyN6TipPkb6iSBWpiFRCSags0AAADuFA From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Cullen Jennings , "Joel M. Halpern" , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, IMHO, Level of Security is a choice available to user, so users should have a control.=20 User doesn't want to control the routing of packets. He cares about it reaching to a particular destination. And here he cares about it reaching with the desired level of security.=20 Users have similar control on the HTTP with HTTPS or by sending a signed documents etc on the email. I see security-level as a variable from the parallel of the anti-virus products also. I care about the anti-virus product to be up-to-date. IMHO, it goes similarly here for cipher-suites/secure protocol etc. Thx Samir PS: I am not from a purist camp. > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Tuesday, August 22, 2006 12:14 PM > To: Srivastava, Samir (SC100:8826) > Cc: Cullen Jennings; Joel M. Halpern; SIP > Subject: Re: [Sip] Ciphersuites in SIP >=20 > "Samir Srivastava" writes: >=20 > > Hi, > > > > Regarding 3) Henry made a nice comment on the sipping list in the > > different context today > > > > "("the Internet is THE service") and the user must have choices and > > control to exercise them. " > > > > So from purists' point of view, proxies in middle need to honor the end > > user wish. Or Am I missing something? >=20 > I think you're missing something. The Internet is a hop-by-hop > data switching service. In general, you get a fairly limited > amount of control over the treatment that the intermediate > switches/routes give your packets provided that they're > routing them towards the destination. For instance, there's > no way in IP to ask routers not to send your packets over > a wireless link. >=20 > -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 15:42:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFc6w-0007hr-RF; Tue, 22 Aug 2006 15:40:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFc6v-0007hl-PC for sip@ietf.org; Tue, 22 Aug 2006 15:40:29 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFc6u-0004b5-Fw for sip@ietf.org; Tue, 22 Aug 2006 15:40:29 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 027B91E8C1C; Tue, 22 Aug 2006 12:40:28 -0700 (PDT) To: "Henry Sinnreich" Subject: Re: [Sip] Ciphersuites in SIP References: <24CCCC428EFEA2469BF046DB3C7A8D22113BA7@namail5.corp.adobe.com> From: Eric Rescorla Date: Tue, 22 Aug 2006 12:40:27 -0700 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22113BA7@namail5.corp.adobe.com> (Henry Sinnreich's message of "Tue, 22 Aug 2006 12:37:02 -0700") Message-ID: <86irkk4l04.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Cullen Jennings , "Joel M. Halpern" , SIP , Yafan An X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Henry Sinnreich" writes: > Eric Rescorla writes: > >> For instance, there's no way in IP to ask routers not to send your >> packets over a wireless link. > > This is true but was not the point discussed here (the first Internet > hop): > > The owner and user of a multimodal wireless device should have the > control to select an access network of his/her choice and the handover > should be controlled from the device, not from the "network". Sure, but this isn't what Samir is arguing for in thuis case. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 15:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcGH-0003xI-8Z; Tue, 22 Aug 2006 15:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcGA-0003uu-JL; Tue, 22 Aug 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFcGA-0005dx-1w; Tue, 22 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0498426E35; Tue, 22 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GFcG9-0003V5-T5; Tue, 22 Aug 2006 15:50:01 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 22 Aug 2006 15:50:01 -0400 X-Spam-Score: -2.3 (--) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: sip@ietf.org, Keith Drage , Dean Willis Subject: [Sip] WG Action: RECHARTER: Session Initiation Protocol (sip) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The charter of the Session Initiation Protocol (sip) working group in the Real-time Applications and Infrastructure Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Session Initiation Protocol (sip) ================================= Current Status: Active Working Group Chair(s): Dean Willis Keith Drage Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Technical Advisor(s): Dan Romascanu Mailing Lists: General Discussion: sip@ietf.org To Subscribe: sip-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/sip/index.html Description of Working Group: The Session Initiation Protocol (SIP) working group is chartered to maintain and continue the development of SIP, currently specified as proposed standard RFC 3261, and its family of extensions. SIP is a text-based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality. The main tasks of the group involve bringing SIP from proposed to draft standard and specifying and developing proposed extensions that arise out of strong requirements. The SIP working group will concentrate on the specification of SIP and its extensions, and will not explore the use of SIP for specific environments or applications. It will, however respond to general- purpose requirements for changes to SIP provided by other working groups, including the SIPPING working group, when those requirements are within the scope and charter of SIP. The process and requirements for such extensions are documented in RFC 3427, "Change Process for the Session Initiation Protocol". Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular: 1. Services and features are provided end-to-end whenever possible. 2. Standards-track extensions and new features must be generally applicable, and not applicable only to a specific set of session types. 3. Simplicity is key. 4. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. The primary source of change requirements to be considered by the SIP Working Group is the SIPPING working group, which analyzes the requirements for application of SIP to several different tasks, including the tasks of standards-development organizations that are developing systems based on SIP and that may require changes or extensions thereto. Additional requirements are produced by the other IETF working groups that are using SIP, including the SIMPLE WG (which is using SIP for messaging and presence) and the XCON working group (which is using SIP for centralized conferencing). In addition to extending SIP as required to address these externally- derived requirements, the deliverables of the group include assuring capable security and privacy mechanisms within SIP and increasing the stability of the SIP specification. Specific deliverables toward these goals include: 1. Mechanisms for secure expression of identity in requests and responses. 2. Mechanism to securely request services delivery by non-terminal elements ("end-to-middle"). 3. Guidelines for use of existing security mechanisms such as TLS, IPsec, and certificates. 4. Guidelines for the use of descriptive techniques such as SAML (Security Association Markup Language) with SIP. 5. Draft standard versions of SIP and critical supporting specifications. Other deliverables may be agreed upon as extensions are understood to be necessary. Prospective deliverables will be discussed with the Area Director before inclusion on agendas, and new proposed work must be approved via a charter update. Goals and Milestones: Done Server Features Negotiation submitted to IESG Done Complete IESG requested fixes to provrel and servfeat Done Revised proposed standard version of SIP (2543bis) submitted to IESG Done SIP Events specification to IESG Done The UPDATE Method submitted for Proposed Standard Done SIP extensions for media authorization (call-auth) submitted as Informational Done Preconditions extensions (manyfolks) spec to IESG Done SIP Privacy specification to IESG Done SIP Privacy and Security Requirements to IESG Done The MESSAGE Method submitted for Proposed Standard Done The Replaces Header submitted for Proposed Standard Done Refer spec to IESG Done SIP NAT extension submitted to IESG Done SIP over SCTP specification and applicability statement Done Mechanism for Content Indirection in SIP submitted to IESG for Proposed Standard Done The SIP Referred-By Header submitted to IESG for Proposed Standard Done Session Timer spec, revised to IESG Done Caller preferences specification submitted to IESG Done Submit SIP Identity documents to IESG for Proposed Standard Done The SIP Join Header submitted to IESG for Proposed Standard Done Replaces header to IESG (PS) Done Upgrade S/MIME requirement for AES in 3261 to IESG (PS) Done Application Interaction to IESG (BCP) Done Presence Publication to IESG (PS) Done Resource Priority signaling mechanism to IESG (PS) Done Guidelines for Authors of SIP extensions submitted as Informational Done Enhancements for Authenticated Identity Management to IESG (BCP) Done MIB spec to IESG Done Request History mechanism to IESG (PS) Done Mechanism for obtaining globally routable unique URIs (GRUU) to WGLC (PS) Done Mechanism for REFER without implicit SUBSCRIBE to IESG (PS) Done Connection reuse mechanism to start WGLC (PS) Done Mechanism for Target-Dialog to IESG (PS) Done Submit Answering/Alerting Modes to the WGLC (PS) Done Addressing an Amplification Vulnerability in Forking Proxies to WGLC (PS) Done Mechanism for feature parameters with REFER To IESG (PS) Done Mechanism for End-to-Middle Requests to IESG (PS) Aug 2006 Submit Answering/Alerting Modes to the IESG (PS) Aug 2006 Mechanism and guidelines for outbound connections to WGLC (PS) Aug 2006 Mechanism for connected identity to WGLC (PS) Aug 2006 Diagnostic Responses for SIP Errors to WGLC (PS) Aug 2006 Consent-Based Communications WGLC (PS) Sep 2006 Mechanism for obtaining globally routable unique URIs (GRUU) to IESG (PS) Sep 2006 Mechanism and guidelines for outbound connections to IESG (PS) Sep 2006 Location Conveyance with SIP to WGLC (PS) Sep 2006 Certificate Management Service for SIP to WGLC (PS) Sep 2006 Rejecting Anonymous Requests to WGLC (PS) Sep 2006 Session Policies to WGLC as PS Sep 2006 Example security flows to WGLC (Informational) Oct 2006 Consent-Based Communications to IESG (PS) Oct 2006 Diagnostic Responses for SIP Errors to IESG (PS) Oct 2006 Rejecting Anonymous Requests to IESG (PS) Oct 2006 Mechanism for connected identity to IESG (PS) Oct 2006 Addressing an Amplification Vulnerability in Forking Proxies to IESG (PS) Oct 2006 Extensions to SIP UA Profile Delivery Change Notification Event Package for XCAP to WGLC (PS) Oct 2006 Refering to Multiple Resources to IESG as PS Nov 2006 Certificate Management Service for SIP to IESG (PS) Nov 2006 Session Policies to IESG as PS Dec 2006 Extensions to SIP UA Profile Delivery Change Notification Event Package for XCAP to IESG (PS) Dec 2006 Location Conveyance with SIP to IESG (PS) Dec 2006 Example security flows to IESG (Informational) Dec 2006 Roadmap for SIP to WGLC (Informational) Mar 2007 Roadmap for SIP to IESG (Informational) Mar 2007 Guidelines for use of SIP security to WGLC (Informational) Apr 2007 Connection reuse mechanism to IESG (PS) Jun 2007 Guidelines for use of SIP security to IESG (Informational) Jun 2007 Identify requirements for test matrix to move SIP to Draft Standard Jun 2007 Revise charter Sep 2007 Using SAML for SIP to WGLC (PS) Dec 2007 Using SAML for SIP to IESG (PS) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 16:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcTA-0003sC-DY; Tue, 22 Aug 2006 16:03:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcT8-0003mf-Iq for sip@ietf.org; Tue, 22 Aug 2006 16:03:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFcT8-0007rA-GF for sip@ietf.org; Tue, 22 Aug 2006 16:03:26 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFcJW-0000iY-Al for sip@ietf.org; Tue, 22 Aug 2006 15:53:35 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.6/IER-o) with ESMTP id k7MJr9Fp008550; Tue, 22 Aug 2006 14:53:10 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k7MJrSX06426; Tue, 22 Aug 2006 14:53:28 -0500 (CDT) Message-ID: <44EB60B8.9010003@lucent.com> Date: Tue, 22 Aug 2006 14:53:28 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: IETF SIP List Subject: [Sip] YAGR (yet another GRUU Review) draft-ietf-sip-gruu-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan/Chairs: I realize that the deadline was yesterday, but I am submitting this review in the hope that it may still be useful. I had followed earlier versions (-00, -01) of the draft, but then other work took over, until now. -10 has changed much since I last remember GRUUs; so as I read it now, I am doing so with very little context (which may be good ... or bad). Summary: RFC3261 mandates that the Contact URI be global and persist beyond the lifetime of a dialog. In practice, this requirement has been hard to meet. This document proposes the notion of a GRUU to mitigate the rfc3261 requirement on the Contact URI. A GRUU persists beyond the lifetime of a dialog, and in addition it is globally routable, even if the UA itself has a private address. Details: Section 4 does a very good job of explaining the use cases that motivate the need for a GRUU. I had a bit of a rough time hunting the information in the document as I had to skip ahed to the examples section when reading sections 5, 7, and 8. Not sure what can be done to alleviate this non-linear reading, though. A major question around the design of the grid parameter I have is this: to indicate to the UAS that the request was sent to a GRUU, the the proxy is required to put a (possibly empty) "grid" parameter when it sends a request to a UAS (cf. towards the end of Section 5 and top of page 20, Section 8.2.1). The proxy is required to remove the "gruu" parameter from this incoming GRUU R-URI before sending it to the UAS, and putting a "grid" parameter. Why not just maintain the "gruu" parameter? Why overload the meaning of "grid" in this manner? It makes it more complex, IMHO (unless there is a reason that I cannot forsee). A couple of places in the text it is maintained that an out-of-dialog request would be indicated by the absence of Route headers. This is not entirely true if there is a pre- loaded Route set, is it? Would the lack of a To-tag not be a better indication of an out-of-dialog request? Once a dialog has been established, To header will have a tag, which will be used in subsequent re-INVs and SUBS. I had trouble following the proxy handling section 8.2.1. The second paragraph lays out what a proxy should do if the R-URI is a GRUU. However, what if the R-URI is not a GRUU? The third paragraph simply assumes that the R-URI is a GRUU ("Otherwise, handling of the GRUU..."). Did you mean "handling of the R-URI instead? I also tried to correlate this section with the example in Section 12 and ran into problems. I will try to list these -- please see if they make sense. WRT Figure 5, an INVITE arrives at the proxy in (3). Since the UAC had no idea that the UAS is reachable using GRUU, it would probably have inserted a R-URI as follows: INVITE sip:callee@example.com SIP/2.0 Now, given this R-URI, I attempted to follow Section 8.2.1 since the request is an out-of-dialog request. The R-URI does not contain a "gruu" parameter, so none of the text in the second paragraph of Section 8.2.1 applies. So I go to the next paragraph. Disregarding the fact that the text uses the word GRUU for the URI (sip:callee@example.com) which is most definately not a GRUU, the proxy does a location server lookup on the URI. What is the expected behavior now? I can see two outcomes: 1) The proxy rejects the request with a 480; or 2) What really happens during the REGISTER processing is that the AoR gets bound to *three* contacts: sip:callee@example.com ----is bound to---> 1/ sip:callee@192.0.2.1 2/ sip:callee@192.0.2.1;gruu; opaque="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" +sip.instance="" 3/ sips:callee@192.0.2.1;gruu; opaque="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" +sip.instance="" So, now if the proxy gets a R-URI of "sip:callee@example.com", it will be mapped to "sip:callee@192.0.2.1" and if the proxy gets a GRUU R-URI of sip:callee@example.com;gruu; opaque="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6", then this will be mapped to: sip:callee@192.0.2.1;grid I suspect that (2) is the right outcome. Yes? Reading between the lines in Section 7.1.2.1 appears to point in that direction as well; especially the fourth paragraph: "...If, after that processing, that contact is bound to the AOR, it also becomes bound to the GRU associated with that instance ID/AOR pair." Is this correct? If so, I would strongly urge that this be highlighted when you talk about the 200 OK response to the REGISTER in the Examples section. Maybe this is obvious to the people who have been involved in GRUU for a long time, but it certainly was not to me. Also in Section 12, I think it will be very helpful to fill in the missing details of the following messages: (4), (7), and (8). Clearly, the proxy R-Rs, following text of Section 8.2.2, and that is why the ACK goes to it. But since the example does not fill in the missing pieces, it is very hard to understand what is going on. Section 8.1.3 says that "If the user agent had previously handed out its GRUU with a "grid" parameter, the incoming Request-URI may contain that parameter." ^^^^ I thought that somewhere it said that the "grid" parameter MUST be reflected in the GRUU by the UAC. If the UAC drops the "grid" parameter, why bother with it at all? In Section 12, you demonstrate the UAC crashing and rebooting. Upon reboot, it gets the same GRUU. Upon getting the 200 OK, the newly rebooted UAC knows that it has a pending, and now stale, registration. Should it not send a REGISTER expiring the GRUU corresponding to the contact sip:callee@192.0.2.1? Nits: * Section 1, fourth paragraph: s/to which the user is/to which the host identified by the IP address is * Section 1, last paragraph: s/the GRUU properties/the GRUU properties (defined in Section 3) * Section 3, towards the end, second to last paragraph: s/of the domain which mints/of the domain that mints * Section 8.1.1 - you may want to consider moving the paragraph "When using a GRUU ... at the "grid" parameter" towards the end; i.e., make it the last paragraph. The reason is that as it is situated right now, it breaks the flow of thinking between the paragraphs bounding it. These talk about GRUUs requiring a visit through intermediaries, whereas the paragraph I point out talks mostly about the "grid" parameter. * Section 8.2.1: s/This produces zero or one contacts/This produces zero or one contact Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 16:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcVK-0004la-Kk; Tue, 22 Aug 2006 16:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcVJ-0004lV-9V for sip@ietf.org; Tue, 22 Aug 2006 16:05:41 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFcVF-0008OA-Vf for sip@ietf.org; Tue, 22 Aug 2006 16:05:41 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7MK5Xo25002; Tue, 22 Aug 2006 16:05:33 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 22 Aug 2006 15:05:31 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DFEF110@zrc2hxm2.corp.nortel.com> In-Reply-To: <86mz9w4l6c.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: AcbGIlJDAL6IzaUYSKCkNPhyjTufgwAA38vg From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Cullen Jennings , "Joel M. Halpern" , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, In line Thx Samir =20 > > He cares about it > > reaching to a particular destination. And here he cares about it > > reaching with the desired level of security. >=20 > That's a perfectly fine argument, but it doesn't follow from > the analogy you're making. Thx you agreed. IMHO, HTTPS makes a closer analogy. On the anti-virus, I was thinking of the secure managed service provided by the providers. >=20 > -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 16:11:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcYl-0005yy-61; Tue, 22 Aug 2006 16:09:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcYj-0005yr-Cs for sip@ietf.org; Tue, 22 Aug 2006 16:09:13 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFcYi-00014R-3C for sip@ietf.org; Tue, 22 Aug 2006 16:09:13 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 8188B1E8C1C; Tue, 22 Aug 2006 13:09:11 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DFEF110@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Tue, 22 Aug 2006 13:09:11 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DFEF110@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Tue, 22 Aug 2006 15:05:31 -0500") Message-ID: <86d5as4jo8.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Cullen Jennings , "Joel M. Halpern" , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > Hi Eric, > > In line > > Thx > Samir > >> > He cares about it >> > reaching to a particular destination. And here he cares about it >> > reaching with the desired level of security. >> >> That's a perfectly fine argument, but it doesn't follow from >> the analogy you're making. > > Thx you agreed. Who said I agree? I'm just saying that it's a valid argument. > IMHO, HTTPS makes a closer analogy. But HTTPS operates exactly the opposite of the way you're suggesting: the client ensures that he has an end-to-end secure connection to the server with the claimed certificate. What happens from there on isn't something it concerns itself with. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 16:16:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFceI-0007rQ-Lr; Tue, 22 Aug 2006 16:14:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFceH-0007rL-B8 for sip@ietf.org; Tue, 22 Aug 2006 16:14:57 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFceG-0002BZ-34 for sip@ietf.org; Tue, 22 Aug 2006 16:14:57 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k7MK8hl18937; Tue, 22 Aug 2006 16:08:44 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 22 Aug 2006 15:14:45 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DFEF140@zrc2hxm2.corp.nortel.com> In-Reply-To: <86d5as4jo8.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: AcbGJuQu2MDrKwe4Q46wGnvRYjcQmwAACeFw From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Cullen Jennings , "Joel M. Halpern" , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Inline Thx Samir > > > > Thx you agreed. >=20 > Who said I agree? I'm just saying that it's a valid argument. >=20 =20 Okay, I didn't read between the lines. >=20 > > IMHO, HTTPS makes a closer analogy. >=20 > But HTTPS operates exactly the opposite of the way you're > suggesting: the client ensures that he has an end-to-end > secure connection to the server with the claimed certificate. > What happens from there on isn't something it concerns > itself with. =20 Here client has control over the connection till the server. After that Server is trusted. >=20 > -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 16:24:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcl9-0002ye-DG; Tue, 22 Aug 2006 16:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcl7-0002y9-4W for sip@ietf.org; Tue, 22 Aug 2006 16:22:01 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFcl4-0003SH-QS for sip@ietf.org; Tue, 22 Aug 2006 16:22:01 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 2ABAF1E8C1F; Tue, 22 Aug 2006 13:21:58 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DFEF140@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Tue, 22 Aug 2006 13:21:58 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DFEF140@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Tue, 22 Aug 2006 15:14:45 -0500") Message-ID: <8664gk4j2x.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Cullen Jennings , "Joel M. Halpern" , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: >> > IMHO, HTTPS makes a closer analogy. >> >> But HTTPS operates exactly the opposite of the way you're >> suggesting: the client ensures that he has an end-to-end >> secure connection to the server with the claimed certificate. >> What happens from there on isn't something it concerns >> itself with. > > Here client has control over the connection till the server. After > that Server is trusted. Yes, and in SIP the proxy is trusted. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 16:27:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcoO-0004Sx-Ek; Tue, 22 Aug 2006 16:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcoN-0004S5-8S for sip@ietf.org; Tue, 22 Aug 2006 16:25:23 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFcoL-0004Ko-Vp for sip@ietf.org; Tue, 22 Aug 2006 16:25:23 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A8220154; Tue, 22 Aug 2006 16:25:06 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" , "'EKR'" Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 22 Aug 2006 16:25:06 -0400 Message-ID: <048001c6c629$0e9ee150$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DFEF03E@zrc2hxm2.corp.nortel.com> Thread-Index: AcbGHyN6TipPkb6iSBWpiFRCSags0AAADuFAAAEJS+A= X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'Cullen Jennings' , "'Joel M. Halpern'" , 'SIP' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Riiiight. And no email server should be allowed to detect email I send as spam or filter virus attachments I add; if it's not my wish. And as for HTTP vs. HTTPS - users don't have control. The admin of the web server they want to access may give them control, by offering both, or not. And when it comes to the SSL version or key length, I've been told users (browsers) usually accept any/all blindly to a degree. But they don't know if there's really an SSL-offloader or not, whether the database backend is secured or not, or much of anything past the other "end" of the TCP/SSL connection. The point is the user has some limited control over the "first hop", and that's it. It's true in SMTP, HTTP, FTP, SSH, BGP, etc. All of them are IETF defined protocols, and part of the "Internet". And this is almost a silly discussion at some point - users don't know about 128 vs. 256 bit keys. Trust me a vast majority of the users on the planet Earth have no idea of what we speak. They only "know" little icons of locks, if that. This is really an argument about UAs trusting proxies, and neither are users. Unless you're telling me UA's shouldn't/won't show a lock icon because it's 128 vs. 256 bit keys, or because we don't have this sip-security header, there's nothing much to argue over IMHO. -hadriel > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: Tuesday, August 22, 2006 3:32 PM > To: EKR > Cc: Cullen Jennings; Joel M. Halpern; SIP > Subject: RE: [Sip] Ciphersuites in SIP > > Hi Eric, > > IMHO, Level of Security is a choice available to user, so users > should have a control. > > User doesn't want to control the routing of packets. He cares about it > reaching to a particular destination. And here he cares about it > reaching with the desired level of security. > > Users have similar control on the HTTP with HTTPS or by sending a signed > documents etc on the email. > > I see security-level as a variable from the parallel of the anti-virus > products also. I care about the anti-virus product to be up-to-date. > IMHO, it goes similarly here for cipher-suites/secure protocol etc. > > Thx > Samir > > PS: I am not from a purist camp. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 16:33:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFctm-0007Ds-Us; Tue, 22 Aug 2006 16:30:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFctl-0007Dn-Ef for sip@ietf.org; Tue, 22 Aug 2006 16:30:57 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFctk-0005Bp-5W for sip@ietf.org; Tue, 22 Aug 2006 16:30:57 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id C60851E8C1C; Tue, 22 Aug 2006 13:30:55 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DFEF181@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Tue, 22 Aug 2006 13:30:55 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DFEF181@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Tue, 22 Aug 2006 15:28:34 -0500") Message-ID: <86y7tg343k.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Cullen Jennings , "Joel M. Halpern" , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > Hi, > > I may go in the circle of arguments which I presented earlier. You're already doing it, which is why I'm repeating my counterarguments. > In short > "Trust and Verify" idiom of Dean captures it clearly with respect to > hop-by-hop nature of SIP. And as I've observed repeatedly, there are a large number of ways for the proxy to screw you so trying to verify this particular one is of extremely limited value. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 17:06:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdOP-0002iz-41; Tue, 22 Aug 2006 17:02:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdOM-0002ip-Qw for sip@ietf.org; Tue, 22 Aug 2006 17:02:34 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFdOL-0001rQ-DE for sip@ietf.org; Tue, 22 Aug 2006 17:02:34 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 22 Aug 2006 14:02:08 -0700 X-IronPort-AV: i="4.08,156,1154934000"; d="scan'208"; a="312802809:sNHT1633450484" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7ML26w6018311; Tue, 22 Aug 2006 14:02:06 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7ML1o6c027579; Tue, 22 Aug 2006 14:02:06 -0700 (PDT) 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); Tue, 22 Aug 2006 17:01:58 -0400 Received: from [161.44.79.169] ([161.44.79.169]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 17:01:56 -0400 Message-ID: <44EB70C4.9080508@cisco.com> Date: Tue, 22 Aug 2006 17:01:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] gruu-10 focused review comments References: <939B827E-F7D3-4D58-A9F2-92E879A0DAB2@nostrum.com> In-Reply-To: <939B827E-F7D3-4D58-A9F2-92E879A0DAB2@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Aug 2006 21:01:56.0831 (UTC) FILETIME=[33E886F0:01C6C62E] DKIM-Signature: a=rsa-sha1; q=dns; l=2257; t=1156280526; x=1157144526; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20gruu-10=20focused=20review=20comments; X=v=3Dcisco.com=3B=20h=3Da/IuyBp5qc4K97n+lpJJdq3SZpA=3D; b=hUJ6hB3jEL9E0YnZxujw/XLWsIYa0FZTTZcjTYY8K1ZmNtSbNPcMY59G8VFgUrUNEZ+8nFAo kv8gAFO1DtizJLXzBR/FupqABKSJaRJ+smTZX+H8ZFPHGhaUXf01csxa; Authentication-Results: sj-dkim-8.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF SIP List , sip-chairs@tools.ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I sent my comments to gruu-09 and Jonathan dealt with them in gruu-10. So I am going to just comment on some of Robert's comments. Paul Robert Sparks wrote: > Location: Section 7.1.2.1 third paragraph page 16 > Nature: minor technical > Comment: Why does the registrar put the instance id in the contact > header field if the request didn't contain Supported: gruu? A registrar > that doesn't know gruu isn't going to do this. A UA that doesn't know > GRUU or outbound isn't going to use it? This looks like a setup for a > subtle interop problem later. I think the problem with the text is only in calling this out as if it was a special action, which it is not. The registrar puts it because it puts all the contact header parameters from the register into the response by default. If the registrar did not support gruu it would still do this. The only special action is inclusion of the "gruu" *header* parameter, containing the assigned gruu. > Location: Section 7.2 4th paragraph last sentence > Nature: editorial/technical > Comment: This requirement is very undermotivated. Why must I include the > gruu parameter here. Who's going to care and do anything different with > it? Normally it would be the thing resolving the GRUU, but in this case, > THAT'S ME, not some other proxy. Why are we trying to put requirements > on how I talk to myself? This is in support of a point that is only hinted at: According to 3261, contacts should always be gruus. But common practice has evolved that they are not. So common practice has also evolved to implement features on the assumption that contacts received from others are not gruus. It does no good to start migrating to a world where contacts may be gruus if you can't tell which are and which are not. That is the purpose of the gruu uri parameter - so that others will believe that this contact is a gruu, and implement their features with that in mind. What is lacking is an explanation of that and a recommendation to implement features assuming the URI is globally routable if it contains a "gruu" parameter. I had been thinking this was already there until I had occasion to go looking for it. (I'm sending that as a comment of my own.) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 17:29:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdmG-0001nA-KK; Tue, 22 Aug 2006 17:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdmE-0001n2-Fh for sip@ietf.org; Tue, 22 Aug 2006 17:27:14 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFdmD-0006hI-5z for sip@ietf.org; Tue, 22 Aug 2006 17:27:14 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k7MLRCY9029619; Tue, 22 Aug 2006 16:27:12 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k7MLRCX13723; Tue, 22 Aug 2006 16:27:12 -0500 (CDT) Message-ID: <44EB76B0.8070508@lucent.com> Date: Tue, 22 Aug 2006 16:27:12 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Updated revision of connect-reuse(draft-ietf-sip-connect-reuse-06) References: <44EA0891.6080909@lucent.com> <000601c6c563$e6e94800$0601a8c0@BEMBUSTER> In-Reply-To: <000601c6c563$e6e94800$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Vijay, > > Regarding virtual servers - it is not that an instant message would end > up in the wrong mailbox, but a secure connection for domain X would get > reused as a connection to domain Y. This has been called "totally > broken" by Cullen > > 1) I wonder, how broken is it really? Could there be cases where the > virtual domain operator may decide to allow this (ie local policy)? > Couldn't it be 'SHOULD' strength? I would think that the behavior that is expected when virtual domains are not used should be equal to the behavior that is exhibited when virtual domains are used. If two domains are hosted on two separate hosts, then there isn't any chance that a connection for domain A on host A' gets used for sending a request to domain B on host B'. Consequently, it seems appropriate that if two domains are hosted on the same physical host, this property of separation be maintained. Specifying a SHOULD strength is a recipe for problems, IMHO. > 2) Since TCP does not provide much security anyway, is there really harm > in sharing TCP connections across virtual domains? Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 18:41:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFetr-0003gU-Nv; Tue, 22 Aug 2006 18:39:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFetq-0003gA-7X for sip@ietf.org; Tue, 22 Aug 2006 18:39:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFczf-0005rk-8C for sip@ietf.org; Tue, 22 Aug 2006 16:37:03 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFcrX-000200-PC for sip@ietf.org; Tue, 22 Aug 2006 16:28:41 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k7MKMWl20320; Tue, 22 Aug 2006 16:22:32 -0400 (EDT) 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 22 Aug 2006 15:28:34 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60DFEF181@zrc2hxm2.corp.nortel.com> In-Reply-To: <8664gk4j2x.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: AcbGKKHy7QKCsEEXT7qkzmxZtZ3E2wAACBow From: "Samir Srivastava" To: "EKR" X-Spam-Score: -2.4 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Cullen Jennings , "Joel M. Halpern" , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I may go in the circle of arguments which I presented earlier. In short "Trust and Verify" idiom of Dean captures it clearly with respect to hop-by-hop nature of SIP. Thx Samir >=20 > Yes, and in SIP the proxy is trusted. >=20 > -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 18:49:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFf27-00016R-JA; Tue, 22 Aug 2006 18:47:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFf25-00016L-Aj for sip@ietf.org; Tue, 22 Aug 2006 18:47:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFcDz-0005SM-D8 for sip@ietf.org; Tue, 22 Aug 2006 15:47:47 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFc3I-00008U-Ag for sip@ietf.org; Tue, 22 Aug 2006 15:36:44 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 89EBB1E8C1C; Tue, 22 Aug 2006 12:36:43 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Ciphersuites in SIP References: <62B9B0847CC47543B6B3B5E26BD268E60DFEF03E@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Tue, 22 Aug 2006 12:36:43 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60DFEF03E@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Tue, 22 Aug 2006 14:31:33 -0500") Message-ID: <86mz9w4l6c.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.4 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Cullen Jennings , "Joel M. Halpern" , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Samir Srivastava" writes: > Hi Eric, > > IMHO, Level of Security is a choice available to user, so users > should have a control. It's available to the user in some settings, but not others. For instance, you can choose to use WEP or WPA, but there's no guarantee that your packets aren't being bridged over some unencrypted wireless network somewhere in the middle of the path. > User doesn't want to control the routing of packets. And yet both IP and SIP provide source routing. > He cares about it > reaching to a particular destination. And here he cares about it > reaching with the desired level of security. That's a perfectly fine argument, but it doesn't follow from the analogy you're making. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 19:23:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfXY-0006hB-HH; Tue, 22 Aug 2006 19:20:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfXX-0006fb-5I for sip@ietf.org; Tue, 22 Aug 2006 19:20:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFdae-0004G8-1X for sip@ietf.org; Tue, 22 Aug 2006 17:15:16 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFdMk-0002f6-0d for sip@ietf.org; Tue, 22 Aug 2006 17:00:58 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Aug 2006 14:00:54 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,156,1154934000"; d="scan'208"; a="37516130:sNHT23708776" 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.20060308/8.12.11) with ESMTP id k7ML0reU019446; Tue, 22 Aug 2006 17:00:53 -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.12.10/8.12.6) with ESMTP id k7ML0quI028295; Tue, 22 Aug 2006 17:00:52 -0400 (EDT) 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, 22 Aug 2006 17:00:52 -0400 Received: from [161.44.79.169] ([161.44.79.169]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 17:00:51 -0400 Message-ID: <44EB7082.5010601@cisco.com> Date: Tue, 22 Aug 2006 17:00:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: IETF SIP List , sip-chairs@tools.ietf.org References: <939B827E-F7D3-4D58-A9F2-92E879A0DAB2@nostrum.com> In-Reply-To: <939B827E-F7D3-4D58-A9F2-92E879A0DAB2@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Aug 2006 21:00:51.0140 (UTC) FILETIME=[0CC0E040:01C6C62E] DKIM-Signature: a=rsa-sha1; q=dns; l=2582; t=1156280453; x=1157144453; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:gruu-10=20focused=20review=20comments |To:IETF=20SIP=20List=20,=20sip-chairs@tools.ietf.org; X=v=3Dcisco.com=3B=20h=3DZdr2cDyEbPzINOZWukSCvjWf5Q8=3D; b=DMdXdWOeVyvKRrc2zB5RL/AfTW264Oi3xrJUINogq9WqbOREFFZtooJmNTPtkXp6Q+S+duzr WlXK+70fwr6eaHU3pVfXmJbgwTOC8yEj+ENeSaG/mSr2Upk0IFYrZsiK; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.4 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [Sip] gruu-10 focused review comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I sent my comments earlier, against -09, and Jonathan dealt with them. But I recently realized I had a new one. Hope it isn't too late. Paul Location: Section 8.1.2 Nature: minor technical Comment: According to 3261, contacts should always be gruus. But common practice has evolved that they are not. So common practice has also evolved to implement features on the assumption that contacts received from others are not gruus. It does no good to start migrating to a world where contacts may be gruus if you can't tell which are and which are not. That is the purpose of the gruu uri parameter - so that others will believe that this contact is a gruu, and implement their features with that in mind. What is lacking is an explanation of that and a recommendation to implement features assuming the URI is globally routable if it contains a "gruu" parameter. I had been thinking this was already there until I had occasion to go looking for it. Suggested fix: Replace the first paragraph as follows: OLD: There is no new behavior associated with sending a request to a GRUU. A GRUU is a URI like any other. When a UA receives a request or response, it knows that the remote target is a GRUU by the presence of the "gruu" URI parameter. The UA can take the GRUU, send a request to it, and then be sure that the request is delivered to the UA instance which sent the request or response. NEW: A GRUU is a URI like any other. When a UA receives a request or response, it knows that the remote target is a GRUU by the presence of the "gruu" URI parameter. The UA can take the GRUU, send a request to it, and then be sure that the request is delivered to the UA instance which sent the request or response. For UACs that have been assuming the URIs in contact headers in messages from others are globally routable there is no new behavior associated with sending a request to that URI when it is a GRUU. However some UACs have been assuming that URIs in received contact headers are not globally routable, and using ad hoc techniques when targetting requests to them. (E.g. Using the To or From-URI instead of the contact URI, or sending a new request in-dialog when an out-of-dialog request would otherwise be preferred.) A GRUU-aware UAC SHOULD treat a URI containing a "gruu" URI-parameter as globally routable, and condition its actions accordingly, if it would otherwise consider that URI to not be globally routable. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 19:36:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFflm-0004Yp-Dt; Tue, 22 Aug 2006 19:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfll-0004Yd-8n for sip@ietf.org; Tue, 22 Aug 2006 19:34:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFedh-0007aw-Lf for sip@ietf.org; Tue, 22 Aug 2006 18:22:29 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53] helo=alnrmhc11.comcast.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFeV2-0003xg-4x for sip@ietf.org; Tue, 22 Aug 2006 18:13:35 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc13) with ESMTP id <20060822221329b1300j9iole>; Tue, 22 Aug 2006 22:13:29 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k7MMDSWI010077 for ; Tue, 22 Aug 2006 18:13:28 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k7MMDSBI010073; Tue, 22 Aug 2006 18:13:28 -0400 Date: Tue, 22 Aug 2006 18:13:28 -0400 Message-Id: <200608222213.k7MMDSBI010073@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: <44EA25CD.20709@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Sip] GRUU-10: "gruu" as both a header and URI parameter References: <2B87277A-D19C-43D2-987B-C8DEA01456D2@estacado.net> <44EA25CD.20709@cisco.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Paul Kyzivat How about "gruu" and "GRUU"? :-) You remember that parameter names are case-insensitive, don't you? (I had to go check -- 19.1.4 and 7.3.1 (top of page 32).) Actually, in this case it doesn't bother me enough to want to change it. But I won't fight against a change. It would help a lot if we had a standardized terminology, but RFC 3261 didn't establish one. At my company, we've used these terms: Contact: ;quux=3 "bar" is a "URI parameter" "Baz" is a "header parameter" "quuz" is a "field parameter" Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 22 22:06:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFi5Q-0001mQ-If; Tue, 22 Aug 2006 22:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFi5P-0001mF-8S for sip@ietf.org; Tue, 22 Aug 2006 22:03:19 -0400 Received: from c243-111.rim.net ([216.9.243.111] helo=MHS02YKF.rim.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFi5O-0001fs-Gb for sip@ietf.org; Tue, 22 Aug 2006 22:03:19 -0400 Importance: normal Priority: normal Received: from ngw01ykf.rim.net ([10.102.108.30]) by MHS02YKF.rim.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Aug 2006 22:03:15 -0400 Received: from XCH20YKF.rim.net ([10.102.100.35]) by ngw01ykf.rim.net (SAVSMTP 3.1.6.45) with SMTP id M2006082222031528627 for ; Tue, 22 Aug 2006 22:03:15 -0400 Received: from XCH47YKF.rim.net ([10.64.31.217]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Aug 2006 22:03:15 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Aug 2006 22:03:12 -0400 Message-ID: <61968779B8AC4C4BAB421D4C12F008C004A78C48@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-sip-gruu-10.txt thread-index: AcbGV/OV63C3OBvXRf6r+haeGPel9w== From: "Andrew Allen" To: X-OriginalArrivalTime: 23 Aug 2006 02:03:15.0871 (UTC) FILETIME=[4BDB1AF0:01C6C658] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea0c5ffa0d480ecee26cc89bc870d672 Cc: Subject: [Sip] Review of draft-ietf-sip-gruu-10.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0952252310==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0952252310== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C658.4BA12E57" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C658.4BA12E57 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Another late review but here are my comments which I hope are not too late to be considered: =20 Section 3 =20 A URI can have any combination of these properties. It is the responsibility of the domain which mints the URI to determine what properties are conferred upon that URI. This specification imposes requirements on a domain that mints a URI with the GRUU property. =20 Have we used the terminology "mints a URI" in SIP drafts before? If not then I think non native English speakers may have some trouble with the term "mints". Consider using "assigns", "allocates" or "manufactures" instead. =20 Section 5 =20 A UA can obtain a GRUU by generating a normal REGISTER request, as specified in RFC 3261 [1]. =20 =20 What is a "normal REGISTER request" or what is an abnormal REGISTER request? Certainly a UA obtaining a GRUU using REGISTER will include extensions in the REGISTER request. I think the word "normal" should be deleted as it doesn't add anything. =20 =20 Section 5 =20 When a proxy in the domain constructs the GRUU, it would set the value of the "opaque" URI parameter such that it includes the instance ID. As such, when that proxy receives a request sent to the GRUU, it can determine that the request is a GRUU by the presence of the "gruu" parameter, and then it can extract the AOR and instance ID, both of which are needed to process the request. =20 =20 This text doesn't align well with the normative procedures in section 9. Certainly it is possible that the "opaque" URI parameter could include the instance ID but it isn't true that in all cases "it would set the value of the "opaque" URI parameter such that it includes the instance ID". Either change "would" to could or "can" or redraft this text to more correctly indicate that the "opaque" URI parameter is set such that it possible for a proxy in the domain to obtain the instance ID. =20 Section 7.1.2.1 =20 A REGISTER request might contain a Require header field; this indicates that the registration has to understand this extension in order to process the request. =20 This doesn't make sense. I think we need to replace "registration has to understand" with "registrar has to understand" =20 Thus should read: =20 A REGISTER request might contain a Require header field; this indicates that the registrar has to understand this extension in order to process the request. =20 =20 Section 8.1.1 =20 If the UA instance has obtained multiple GRUUs for different AORs as a result of a registration, it SHOULD use one corresponding to the AOR used to send or receive the request. For sending a request, this means that the GRUU corresponds to the AOR present in the From header field. =20 =20 And =20 The GRUU placed into the Contact header field of the response SHOULD correspond to the AOR to which the request was targeted by the peer. =20 =20 An issue that I think should be discussed is what happens when a UA uses a TEL URI to send a request. What GRUU should be used in this case? draft-ietf-sipping-gruu-reg-event provides a mechanism that could be used by the domain to provide the UA with a GRUU for TEL URIs however currently draft-ietf-sip-gruu doesn't mention use with TEL URIs at all or provide any guidance on the allocation of GRUUs for use with TEL URIs. Since a GRUU cannot be a TEL URI the property of being able to obtain the identity used from the GRUU doesn't exist.=20 =20 Section 8.2.1 =20 Otherwise, handling of the GRUU proceeds as specified in RFC 3261 Section 16. For GRUUs, the abstract location service described in Section 16.5 is utilized, producing a set of zero or more contacts, each of which is associated with the same instance ID.=20 =20 Second sentence should contain RFC 3261 for the Section 16.5 reference to avoid confusion whether this reference is within the present document. =20 =20 Andrew =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 --------------------------------------------------------------------- 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. ------_=_NextPart_001_01C6C658.4BA12E57 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Another late review but here are my comments which I = hope are not too late to be considered:

 

Section 3

 

   A URI = can have any combination of these properties.  It is = the

   = responsibility of the domain which mints the URI to determine = what

   = properties are conferred upon that URI.  This specification = imposes

   = requirements on a domain that mints a URI with the GRUU = property.

 

Have we used the = terminology “mints a URI” in SIP drafts before? If not then I think non = native English speakers may have some trouble with the term = “mints”. Consider using “assigns”, “allocates” or = “manufactures” instead.

 

Section = 5

 

   A UA = can obtain a GRUU by generating a normal REGISTER request, = as

   = specified in RFC 3261 [1]. 

 

What is a = “normal REGISTER request” or what is an abnormal REGISTER request? = Certainly a UA obtaining a GRUU using REGISTER will include extensions in the REGISTER request. I think the word “normal” should be deleted as it doesn’t add anything.

 

 

Section 5

 

   When a = proxy in the domain constructs the GRUU, it would set = the

   value = of the "opaque" URI parameter such that it includes = the

   = instance ID.  As such, when that proxy receives a request sent to = the

   GRUU, = it can determine that the request is a GRUU by the presence = of

   the "gruu" parameter, and then it can extract the AOR and = instance

   ID, = both of which are needed to process the request.

 

 

This text doesn’t = align well with the normative procedures in section 9. Certainly it is possible = that the “opaque” URI parameter could include the instance ID but it isn’t true that in all cases “it would set the value of the "opaque" URI parameter such that it includes the instance ID”. Either change “would” to = could or “can” or redraft this text to more correctly indicate that = the "opaque" URI parameter is set such that it possible for a = proxy in the domain to obtain the instance ID.

 

Section = 7.1.2.1

 

   A = REGISTER request might contain a Require header field; = this

   = indicates that the registration has to understand this extension = in

   order = to process the request.

 

This doesn’t = make sense. I think we need to replace “registration has to = understand” with “registrar has to = understand”

 

Thus should = read:

 

   A = REGISTER request might contain a Require header field; = this

   = indicates that the registrar has to understand this extension = in

   order = to process the request.

 

 

Section = 8.1.1

 

   If the = UA instance has obtained multiple GRUUs for different AORs = as

   a = result of a registration, it SHOULD use one corresponding to = the

   AOR = used to send or receive the request.  For sending a request, = this

   means = that the GRUU corresponds to the AOR present in the From = header

   = field. 

 

And

 

   The = GRUU placed into the Contact header field of the response = SHOULD

   = correspond to the AOR to which the request was targeted by the = peer.

 

 

An issue that I = think should be discussed is what happens when a UA uses a TEL URI to send a request. = What GRUU should be used in this case? draft-ietf-sipping-gruu-reg-event = provides a mechanism that could be used by the domain to provide the UA with a GRUU = for TEL URIs however currently draft-ietf-sip-gruu doesn’t mention use = with TEL URIs at all or provide any guidance on the allocation of GRUUs for = use with TEL URIs. Since a GRUU cannot be a TEL URI the property of being able to = obtain the identity used from the GRUU doesn’t exist. =

 

Section = 8.2.1

 

   = Otherwise, handling of the GRUU proceeds as specified in RFC = 3261

   = Section 16.  For GRUUs, the abstract location service described = in

   = Section 16.5 is utilized, producing a set of zero or more = contacts,

   each = of which is associated with the same instance ID.

 

Second sentence = should contain RFC 3261 for the Section 16.5 reference to avoid confusion = whether this reference is within the present document.

 

 

Andrew

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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. ------_=_NextPart_001_01C6C658.4BA12E57-- --===============0952252310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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 --===============0952252310==-- From sip-bounces@ietf.org Tue Aug 22 22:59:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFivU-0006lt-9V; Tue, 22 Aug 2006 22:57:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFivS-0006ju-CR for sip@ietf.org; Tue, 22 Aug 2006 22:57:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFijL-00080e-Au for sip@ietf.org; Tue, 22 Aug 2006 22:44:37 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Aug 2006 22:44:35 -0400 X-IronPort-AV: i="4.08,157,1154923200"; d="scan'208"; a="98142831:sNHT32827540" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7N2iZHG026718; Tue, 22 Aug 2006 22:44:35 -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.12.10/8.12.6) with ESMTP id k7N2iYdM018247; Tue, 22 Aug 2006 22:44:34 -0400 (EDT) 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); Tue, 22 Aug 2006 22:44:34 -0400 Received: from [10.86.241.62] ([10.86.241.62]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 22:44:34 -0400 Message-ID: <44EBC111.5030207@cisco.com> Date: Tue, 22 Aug 2006 22:44:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Dean Willis References: <939B827E-F7D3-4D58-A9F2-92E879A0DAB2@nostrum.com> <44EB7082.5010601@cisco.com> <54F82451-70EA-46C1-956A-429074445209@softarmor.com> In-Reply-To: <54F82451-70EA-46C1-956A-429074445209@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2006 02:44:34.0267 (UTC) FILETIME=[111852B0:01C6C65E] DKIM-Signature: a=rsa-sha1; q=dns; l=3181; t=1156301075; x=1157165075; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20gruu-10=20focused=20review=20comments |To:Dean=20Willis=20; X=v=3Dcisco.com=3B=20h=3DGZYMIcm36KO50ElgzFQc7wfwU4M=3D; b=a9vvVXXNkrgtavUimrXyhnRaDhIlAi+W5rKNeedl8lzycjoqyzOU7sZHyqv/FmVnsGquPzyh jnEsv2Jn8gipmQEc7FmlCwox6ntDDf00aWBwxYvfL6AXZpFPV6T3cwJH; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: IETF SIP List , sip-chairs@tools.ietf.org Subject: [Sip] Re: gruu-10 focused review comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Aug 22, 2006, at 4:00 PM, Paul Kyzivat wrote: > > I'll paste my confusion in-line. > >> Suggested fix: Replace the first paragraph as follows: >> >> OLD: >> There is no new behavior associated with sending a request to a GRUU. >> A GRUU is a URI like any other. When a UA receives a request or >> response, it knows that the remote target is a GRUU by the presence >> of the "gruu" URI parameter. The UA can take the GRUU, send a >> request to it, and then be sure that the request is delivered to the >> UA instance which sent the request or response. >> >> NEW: >> A GRUU is a URI like any other. When a UA receives a request or >> response, it knows that the remote target is a GRUU by the presence >> of the "gruu" URI parameter. The UA can take the GRUU, send a >> request to it, and then be sure that the request is delivered to the >> UA instance which sent the request or response. > > But we've already got people talking about redirecting or retargeting > requests that were sent to a GRUU -- perhaps in the UA, or perhaps in > some proxy. > > And the GRUU, despite being "universally routable", isn't necessarily > reachable. It is just more likely to be reachable than the real Contact. That is the part I left unchanged from the original. >> For UACs that have been assuming the URIs in contact headers in >> messages from others are globally routable there is no new behavior >> associated with sending a request to that URI when it is a GRUU. >> > > I like the preceding. > >> However some UACs have been assuming that URIs in received contact >> headers are not globally routable, and using ad hoc techniques when >> targetting requests to them. (E.g. Using the To or From-URI instead >> of the contact URI, or sending a new request in-dialog when an >> out-of-dialog request would otherwise be preferred.) A GRUU-aware >> UAC SHOULD treat a URI containing a "gruu" URI-parameter as globally >> routable, and condition its actions accordingly, if it would >> otherwise consider that URI to not be globally routable. >> > > But the last sentence of the preceding lost me. It's a URI. Since I know > it is supposed to be a GRUU, I should try it before trying tricky > transforms on the other URIs I have available (including AOR). But I > might NOT actually be able to reach it. Are there still use cases where > I'm going to fall back and try something tricky? I guess I'm not being successful in saying what I mean. I'm classifying UAs into two classes: - those that assume a contact is globally routable and use it when implementing features. (E.g. Refer-To it.) - those that do something else. (e.g. Refer-To the To-URI.) When the first kind are updated to support gruu they don't need to do nothing new. When the second kind are updated to support gruu, they can continue unchanged for contacts lacking the gruu parameter. But for contacts containing the gruu parameter they should give up their paranoia and act like the first kind. Paul > -- > Dean > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 23 01:19:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFl5v-00066B-PC; Wed, 23 Aug 2006 01:16:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFl5t-000665-Qj for sip@ietf.org; Wed, 23 Aug 2006 01:16:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFin4-0008Jk-9C for sip@ietf.org; Tue, 22 Aug 2006 22:48:26 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFi6T-0001Lg-84 for sip@ietf.org; Tue, 22 Aug 2006 22:04:27 -0400 Received: from [192.168.2.106] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7N26fwF018340 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 22 Aug 2006 21:06:42 -0500 In-Reply-To: <44EB7082.5010601@cisco.com> References: <939B827E-F7D3-4D58-A9F2-92E879A0DAB2@nostrum.com> <44EB7082.5010601@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54F82451-70EA-46C1-956A-429074445209@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 22 Aug 2006 21:04:13 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.6 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: IETF SIP List , sip-chairs@tools.ietf.org Subject: [Sip] Re: gruu-10 focused review comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 22, 2006, at 4:00 PM, Paul Kyzivat wrote: I'll paste my confusion in-line. > Suggested fix: Replace the first paragraph as follows: > > OLD: > There is no new behavior associated with sending a request to a > GRUU. > A GRUU is a URI like any other. When a UA receives a request or > response, it knows that the remote target is a GRUU by the presence > of the "gruu" URI parameter. The UA can take the GRUU, send a > request to it, and then be sure that the request is delivered to > the > UA instance which sent the request or response. > > NEW: > A GRUU is a URI like any other. When a UA receives a request or > response, it knows that the remote target is a GRUU by the presence > of the "gruu" URI parameter. The UA can take the GRUU, send a > request to it, and then be sure that the request is delivered to > the > UA instance which sent the request or response. But we've already got people talking about redirecting or retargeting requests that were sent to a GRUU -- perhaps in the UA, or perhaps in some proxy. And the GRUU, despite being "universally routable", isn't necessarily reachable. It is just more likely to be reachable than the real Contact. > > For UACs that have been assuming the URIs in contact headers in > messages from others are globally routable there is no new behavior > associated with sending a request to that URI when it is a GRUU. > I like the preceding. > However some UACs have been assuming that URIs in received contact > headers are not globally routable, and using ad hoc techniques when > targetting requests to them. (E.g. Using the To or From-URI instead > of the contact URI, or sending a new request in-dialog when an > out-of-dialog request would otherwise be preferred.) A GRUU-aware > UAC SHOULD treat a URI containing a "gruu" URI-parameter as > globally > routable, and condition its actions accordingly, if it would > otherwise consider that URI to not be globally routable. > But the last sentence of the preceding lost me. It's a URI. Since I know it is supposed to be a GRUU, I should try it before trying tricky transforms on the other URIs I have available (including AOR). But I might NOT actually be able to reach it. Are there still use cases where I'm going to fall back and try something tricky? -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 23 09:12:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsU5-00054G-7O; Wed, 23 Aug 2006 09:09:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsU3-00052J-EK for sip@ietf.org; Wed, 23 Aug 2006 09:09:27 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFsU2-0000Hz-4q for sip@ietf.org; Wed, 23 Aug 2006 09:09:27 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k7ND9JqZ010881; Wed, 23 Aug 2006 08:09:19 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k7ND9IK14222; Wed, 23 Aug 2006 08:09:19 -0500 (CDT) Message-ID: <44EC537E.3000905@lucent.com> Date: Wed, 23 Aug 2006 08:09:18 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] GRUU-10: "gruu" as both a header and URI parameter References: <2B87277A-D19C-43D2-987B-C8DEA01456D2@estacado.net> <44EA25CD.20709@cisco.com> <200608222213.k7MMDSBI010073@dragon.ariadne.com> In-Reply-To: <200608222213.k7MMDSBI010073@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net wrote: > It would help a lot if we had a standardized terminology, but RFC 3261 > didn't establish one. At my company, we've used these terms: > > Contact: ;quux=3 > > "bar" is a "URI parameter" > "Baz" is a "header parameter" > "quuz" is a "field parameter" RFC 3261 does try to use the same terminology, except that the use of "header" is overloaded. For instance, what you refer to as a "field parameter" above is actually termed as a "header parameter" in RFC 3261 in a very consistent manner. In fact, Section 20.10 attempts to make a distinction between a URI parameter and a header parameter. Unfortunately, rfc3261 also calls the construct "?Baz=2" as a header. That is what I think is problematic, since "Contact" is a header as well. But the intent was that anything following the ? would be headers that could potentially appear on a line by themselves when someone clicks on that URI. For instance, sip:vkg@lucent.com?Subject="Call%20Me"&method=INVITE would get translated to INVITE sip:vkg@lucent.com SIP/2.0 Subject: Call Me ... Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 23 09:35:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsqX-0007X3-9D; Wed, 23 Aug 2006 09:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsqV-0007Wx-Ja for sip@ietf.org; Wed, 23 Aug 2006 09:32:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFsqU-0004V2-6j for sip@ietf.org; Wed, 23 Aug 2006 09:32:39 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2006 09:32:38 -0400 X-IronPort-AV: i="4.08,160,1154923200"; d="scan'208"; a="98229993:sNHT35813674" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7NDWb8L001747; Wed, 23 Aug 2006 09:32:37 -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.12.10/8.12.6) with ESMTP id k7NDWVdQ004521; Wed, 23 Aug 2006 09:32:37 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 09:32:31 -0400 Received: from [161.44.79.169] ([161.44.79.169]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 09:32:30 -0400 Message-ID: <44EC58EE.2070403@cisco.com> Date: Wed, 23 Aug 2006 09:32:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] GRUU-10: in-vs-out-of-dialog gruu retargetting References: <850EF6C5-45B9-431D-9B81-6FBB4D38EC2F@estacado.net> In-Reply-To: <850EF6C5-45B9-431D-9B81-6FBB4D38EC2F@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2006 13:32:31.0020 (UTC) FILETIME=[95720EC0:01C6C6B8] DKIM-Signature: a=rsa-sha1; q=dns; l=3914; t=1156339957; x=1157203957; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20GRUU-10=3A=20in-vs-out-of-dialog=20gruu=20retargetting |To:Robert=20Sparks=20; X=v=3Dcisco.com=3B=20h=3Da1eLiFwO3kodOkc/NDo3yMn9mec=3D; b=qwLTqaY4cwkPjJyHfsG6JxiYEkdn7qxS80AqOsePe7d+EOMhlxoFMskHgFrdcP0DC6t9FSXi Su4MNajH9kmSA9Mk3UoFWNMEhpbGKT8LauBfCEYbHStq30mgCofzr5Ad; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: IETF SIP List , sip-chairs@tools.ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Robert - I'll take a crack at this... Robert Sparks wrote: > I forced myself (1) to forget the various conversations we had around > last-hop-spiraling and the interaction of GRUU with outbound and tried > to read the proxy behavior section from the point-of-view of an > implementer who didn't have the list/meeting history in their head. With > those preconditions 8.2.1 through 8.2.3 get somewhat confusing. > > First - It's not clear why there's any distinction between in-dialog and > out-of-dialog requests in the first place. > That distinction isn't normal for a proxy - what's special that makes it > normal here? After looking at this for a long time I came to a conclusion that 3261 isn't very clear on one important point that is relevant here: If a proxy receives a request that still has Route headers, but the proxy is also responsible for the domain of the R-URI, should it then translate the R-URI (and then route based on the Route header), or should it leave the R-URI unchanged and route on the Route header? I always assumed it was clear that it should leave the R-URI unchanged in this case, assuming it will spiral back for translation later. But I haven't been able to find any language that dictates that. If the proxy were to do the translation even though there are Route headers, to an R-URI for which there is a registration with a Path, there is then a question of how the values for the Path are merged with those remaining in the Route header. That isn't a problem if you wait till the Route header is exhausted. However, when using GRUUs, and when there are record-routed proxies between the home proxy and the UAS, that leads to spirals. What has been done to eliminate the spirals is to specify a case when the translation should be done before the route headers are exhausted, as well as an algorithm for handling the merge of the Path with the remaining Route headers. Its good enough for this case, but probably not for all cases. Before this approach was adopted, Jonathan had proposed that proxies adjust their record-routing behavior based on the use of a GRUU as contact. I did a *lot* of head scratching trying to make that work (for IMS), and just couldn't get it. After that, Jonathan switched to this. Perhaps the interaction between translation, Route, and Path should be changed for all cases. But I'm not convinced it is easy in general as it is in the gruu case. I expect that would be entwined with the jonathan's route-construct draft. (That probably has some rough going because it is incompatible with certain well known usages.) Paul > Next, if it is necessary to distinguish them, the criteria currently in > the draft won't work. You can have out-of-dialog > requests show up with Route headers fields. > > The only difference in behavior that I can back out of the current text > (did I miss something?) is dealing with the situation > where there is more than one contact currently bound to the GRUU. 8.2.1 > says to use the most recent, 8.2.3 says to > pick arbitrarily. To the implementer, this is going to appear arcane at > best. > > Do we really _need_ the distinction? Can we not reduce the whole of > section 8.2 down to one or two paragraphs by > unifying those sections? (3261 asks you to record-route mid-dialog > requests anyhow, so we should be able to > roll the 8.2.2 in at the same time). > > RjS > > (1) Well, I didn't really have to use much force in order to forget > _that_ stuff. :O > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 23 10:58:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFu9C-00035R-Hb; Wed, 23 Aug 2006 10:56:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFu9A-00035M-Vd for sip@ietf.org; Wed, 23 Aug 2006 10:56:00 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFu99-0005ql-M4 for sip@ietf.org; Wed, 23 Aug 2006 10:56:00 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2006 07:42:52 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,160,1154934000"; d="scan'208"; a="37654226:sNHT27917040" 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.20060308/8.12.11) with ESMTP id k7NEgqjm020436; Wed, 23 Aug 2006 10:42:52 -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.12.10/8.12.6) with ESMTP id k7NEgquI004202; Wed, 23 Aug 2006 10:42:52 -0400 (EDT) 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); Wed, 23 Aug 2006 10:42:52 -0400 Received: from [161.44.79.169] ([161.44.79.169]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 10:42:51 -0400 Message-ID: <44EC696A.3010001@cisco.com> Date: Wed, 23 Aug 2006 10:42:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] Updated revision of connect-reuse (draft-ietf-sip-connect-reuse-06) References: <44EA0891.6080909@lucent.com> In-Reply-To: <44EA0891.6080909@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2006 14:42:51.0759 (UTC) FILETIME=[6933B7F0:01C6C6C2] DKIM-Signature: a=rsa-sha1; q=dns; l=2227; t=1156344172; x=1157208172; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Updated=20revision=20of=20connect-reuse=09(draft-ietf-si p-connect-reuse-06) |To:=22Vijay=20K.=20Gurbani=22=20; X=v=3Dcisco.com=3B=20h=3DdOexKe54N7I0f7YP9nJ8tuhhl4k=3D; b=phM1QyDiLXXptZr3IO146mywdhq9r+dGk/YOIrAq7fi28iHp7dcmQnI+kGKHxLAGQzRmb/k3 BxtGjFbno89oSQ6VViNtW6ehSWE98RbDFTzvGLajtxj+imsuun8a5PwJ; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is shaping up - much more comprehensible than earlier versions. But there still seem to be some loose ends to clean up. Here are notes I made while reading through this version. Paul Section 2 The connect reuse mechanism described in this document is defined only for Transport Layer Security (TLS) transports. The doc seems to be schizophrenic about this. It continues to talk about connection reuse of TCP connections, but using different connections in each direction. Not clear if that is intended as a true part of the specification, as some non-normative text about a usage that is already defined elsewhere, or simply as obsolete text that hasn't been removed. Section 8.1 The implications of placing an "alias" parameter in the topmost Via header of a request must be understood by the client. Specifically, this means that the client MUST keep the connection open for as long as the resources on the host operating system allow it to, and that it MUST accept requests over this connection -- as opposed to a default listening port -- from its downstream peer. And furthermore, The condition "as opposed to a default listening port" is wrong, and contradicted later in the text. I think you mean to say "in addition to the default listening port". TCP connections, obviously, cannot be authenticated in a similar manner as TLS connections; nor can an identity be derived by inspecting fields of a certificate. For TCP connections, clients MUST use as the destination identity the URI used as input to the RFC3263 server resolution process. This seems obsolete, since reuse is no longer supported for TCP. Section 9.2: (nit) this case, the alias table MUST not be updated. I think that should be this case, the alias table MUST NOT be updated. Section 10.2 (Virtual Servers and TCP Connections) I don't follow this at all. I see absolutely no reason why the same connection should not be used for atlanta.example.com and chicago.example.com if the resolve to the same address. (But then apparently any discussion of TCP connection reuse should be out of scope anyway.) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 23 12:23:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvSz-00083b-9Q; Wed, 23 Aug 2006 12:20:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvSy-000838-1U for sip@ietf.org; Wed, 23 Aug 2006 12:20:32 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvSw-00035J-O1 for sip@ietf.org; Wed, 23 Aug 2006 12:20:32 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k7NGKRQL011995; Wed, 23 Aug 2006 11:20:27 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k7NGKRK06990; Wed, 23 Aug 2006 11:20:27 -0500 (CDT) Message-ID: <44EC804B.2020706@lucent.com> Date: Wed, 23 Aug 2006 11:20:27 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Updated revision of connect-reuse (draft-ietf-sip-connect-reuse-06) References: <44EA0891.6080909@lucent.com> <44EC696A.3010001@cisco.com> In-Reply-To: <44EC696A.3010001@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > This is shaping up - much more comprehensible than earlier versions. > But there still seem to be some loose ends to clean up. Paul: Thanks for your time in reading -06. I am also glad that you found it much more easier to follow than earlier revisions; we put in a fair amount of edits for clarity in this version. More inline. > Section 2 > > The connect reuse mechanism described in this document is defined > only for Transport Layer Security (TLS) transports. > > The doc seems to be schizophrenic about this. It continues to talk > about connection reuse of TCP connections, but using different > connections in each direction. Not clear if that is intended as a > true part of the specification, as some non-normative text about a > usage that is already defined elsewhere, or simply as obsolete text > that hasn't been removed. You are right about the schizophrenic nature of TCP connection reuse. Earlier versions mainly wanted to do TLS reuse; but I think that it is important to provide TCP connection reuse as well, but because of the security problems associated with doing TCP connection reuse a la TLS, it is best to open up a connection in each direction. It'll be great to provide normative behavior for TCP connection reuse in this document, especially now as the use of TCP in SIP increases. If we do not provide any guidance, then implementations will have at least two different sets of behaviors: 1) Reuse the TCP connection in the backwards direction, a la TLS. This pitfalls of doing so are listed in Section 9.3. 2) Open up two connections for reuse, as this draft recommends. For interoperability, it'll be good to have one behavior and it'll be even better if this information is maintained in one document (as opposed to having a connection reuse document for TLS and another for TCP). What do others in the WG think? > The condition "as opposed to a default listening port" is wrong, and > contradicted later in the text. I think you mean to say "in addition > to the default listening port". Yes; corrected. > I think that should be > > this case, the alias table MUST NOT be updated. Yes; corrected. Thanks. > Section 10.2 (Virtual Servers and TCP Connections) > > I don't follow this at all. I see absolutely no reason why the same > connection should not be used for atlanta.example.com and > chicago.example.com if the resolve to the same address. Hmmm...Jeroen also made the same comment. So maybe I need to re-look at that section. I was trying to partition the namespace for the server hosting the virtual domains such that requests in the backwards direction would result in a distinct TCP connection for each domain. But maybe this is overkill. Any other opinions? Thanks much for your time on this. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 23 13:12:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwEM-0007VQ-7q; Wed, 23 Aug 2006 13:09:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFc4i-0007BR-Cf for sip@ietf.org; Tue, 22 Aug 2006 15:38:12 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFc4f-00045u-EB for sip@ietf.org; Tue, 22 Aug 2006 15:38:12 -0400 Received: from source ([192.150.20.142]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Tue, 22 Aug 2006 12:38:02 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k7MJbwuv011710; Tue, 22 Aug 2006 12:38:00 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k7MJbUR6027288; Tue, 22 Aug 2006 12:37:35 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 12:37:32 -0700 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 Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 22 Aug 2006 12:37:02 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22113BA7@namail5.corp.adobe.com> In-Reply-To: <868xlg60sv.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: AcbGH161qrSygat4TyiSF3J56TVC/QAALnNA From: "Henry Sinnreich" To: "EKR" , "Samir Srivastava" X-OriginalArrivalTime: 22 Aug 2006 19:37:32.0722 (UTC) FILETIME=[6976D120:01C6C622] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-Mailman-Approved-At: Wed, 23 Aug 2006 13:09:29 -0400 Cc: Cullen Jennings , "Joel M. Halpern" , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Rescorla writes: > For instance, there's no way in IP to ask routers not to send your=20 > packets over a wireless link. This is true but was not the point discussed here (the first Internet hop): The owner and user of a multimodal wireless device should have the control to select an access network of his/her choice and the handover should be controlled from the device, not from the "network". The Media Independent Handover work IEEE 802.21 can be found for example at http://www.cs.tut.fi/kurssit/83180/83180_05_S9d.ppt and explicitly provides the option selection and handover control from the mobile device. Thanks, Henry -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Tuesday, August 22, 2006 2:14 PM To: Samir Srivastava Cc: Cullen Jennings; Joel M. Halpern; SIP Subject: Re: [Sip] Ciphersuites in SIP "Samir Srivastava" writes: > Hi, > > Regarding 3) Henry made a nice comment on the sipping list in the > different context today > > "("the Internet is THE service") and the user must have choices and > control to exercise them. " > > So from purists' point of view, proxies in middle need to honor the end > user wish. Or Am I missing something? I think you're missing something. The Internet is a hop-by-hop data switching service. In general, you get a fairly limited=20 amount of control over the treatment that the intermediate switches/routes give your packets provided that they're routing them towards the destination. For instance, there's no way in IP to ask routers not to send your packets over a wireless link. -Ekr _______________________________________________ Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Wed Aug 23 13:12:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwFa-0007ab-7R; Wed, 23 Aug 2006 13:10:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcy8-0000eJ-7e for sip@ietf.org; Tue, 22 Aug 2006 16:35:28 -0400 Received: from nat.stoke.com ([209.78.40.100] helo=trio.stoke.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFcy6-0005dy-SZ for sip@ietf.org; Tue, 22 Aug 2006 16:35:28 -0400 Received: from us.stoke.com (minsk.us.stoke.com [172.16.4.20]) by trio.stoke.com (8.13.3/8.13.3) with ESMTP id k7MKZIY9055474 for ; Tue, 22 Aug 2006 13:35:18 -0700 (PDT) (envelope-from yafan@stoke.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ciphersuites in SIP Date: Tue, 22 Aug 2006 13:37:06 -0700 Message-ID: <23EECEC9B06584478B1C9E38C253D35F74ADC5@minsk.us.stoke.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ciphersuites in SIP Thread-Index: AcbGIxeVFihgX2PlQpijpSHpS2qU1gABWjIA From: "Yafan An" To: "EKR" , "Henry Sinnreich" X-Virus-Scanned: ClamAV 0.88/1709/Tue Aug 22 12:34:50 2006 on trio.stoke.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Wed, 23 Aug 2006 13:10:44 -0400 Cc: Cullen Jennings , "Joel M. Halpern" , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Control" can be: 1) Owner set the policy=20 2) Network node executes the policy and procedures Without the specifics, such as 1) What to control (e.g. performance, cost to user, and cost to network, etc.); 2) Means of control I feel the terms are quoted out of the context too much. Yafan -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Tuesday, August 22, 2006 12:40 PM To: Henry Sinnreich Cc: Samir Srivastava; Cullen Jennings; Joel M. Halpern; SIP; Yafan An Subject: Re: [Sip] Ciphersuites in SIP "Henry Sinnreich" writes: > Eric Rescorla writes: > >> For instance, there's no way in IP to ask routers not to send your=20 >> packets over a wireless link. > > This is true but was not the point discussed here (the first Internet > hop): > > The owner and user of a multimodal wireless device should have the > control to select an access network of his/her choice and the handover > should be controlled from the device, not from the "network". Sure, but this isn't what Samir is arguing for in thuis case. -Ekr _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 23 16:12:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFz2U-0001aE-2m; Wed, 23 Aug 2006 16:09:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFz2S-0001ZV-7p for sip@ietf.org; Wed, 23 Aug 2006 16:09:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFxRy-0004TH-LD for sip@ietf.org; Wed, 23 Aug 2006 14:27:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFxDE-0007aU-PQ for sip@ietf.org; Wed, 23 Aug 2006 14:12:27 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 23 Aug 2006 11:12:22 -0700 X-IronPort-AV: i="4.08,161,1154934000"; d="scan'208"; a="313142397:sNHT33347848" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7NICLps028733; Wed, 23 Aug 2006 11:12:21 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7NICKw9013180; Wed, 23 Aug 2006 11:12:21 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 14:12:20 -0400 Received: from [161.44.79.169] ([161.44.79.169]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 14:12:20 -0400 Message-ID: <44EC9A83.4090907@cisco.com> Date: Wed, 23 Aug 2006 14:12:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] Updated revision of connect-reuse (draft-ietf-sip-connect-reuse-06) References: <44EA0891.6080909@lucent.com> <44EC696A.3010001@cisco.com> <44EC804B.2020706@lucent.com> In-Reply-To: <44EC804B.2020706@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2006 18:12:20.0387 (UTC) FILETIME=[ACB02730:01C6C6DF] DKIM-Signature: a=rsa-sha1; q=dns; l=803; t=1156356741; x=1157220741; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Updated=20revision=20of=20connect-reuse=20(draft-ietf-si p-connect-reuse-06); X=v=3Dcisco.com=3B=20h=3DdOexKe54N7I0f7YP9nJ8tuhhl4k=3D; b=iKG288VRjzDdjROSmwdYPGytJ/36/7BatsRzBZy0rr5w9xxqRMA1c5Q+EUKfo6WewGgt73yn fH8awIup0plzzEbTgRE885djSVwsbtdl/7cZ2YtOYmnTz6uwH20VZh4R; Authentication-Results: sj-dkim-8.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.4 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: >> Section 10.2 (Virtual Servers and TCP Connections) >> >> I don't follow this at all. I see absolutely no reason why the same >> connection should not be used for atlanta.example.com and >> chicago.example.com if the resolve to the same address. > > Hmmm...Jeroen also made the same comment. So maybe I need to > re-look at that section. I was trying to partition the > namespace for the server hosting the virtual domains such that > requests in the backwards direction would result in a distinct > TCP connection for each domain. But maybe this is overkill. > Any other opinions? There won't be any requests in the backwards direction. There will be a separate connection for each direction. That is the key difference from the TLS approach. Paul _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 23 17:56:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0fR-0000vp-Kx; Wed, 23 Aug 2006 17:53:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0fQ-0000vC-FK for sip@ietf.org; Wed, 23 Aug 2006 17:53:44 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG0fP-0004vY-5o for sip@ietf.org; Wed, 23 Aug 2006 17:53:44 -0400 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 k7NLlal07911 for ; Wed, 23 Aug 2006 17:47:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6C6FE.97FF3AEB" Date: Wed, 23 Aug 2006 16:53:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0C834F94@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-audet-sip-sips-guidelines-03.txt Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQ From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Sip] draft-audet-sip-sips-guidelines-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C6FE.97FF3AEB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I want to draw people's attention to a revision of the SIPS guidelines=20 draft: http://www.ietf.org/internet-drafts/draft-audet-sip-sips-guidelines-03.t xt. The intent is to re-issue this a a working group document as per the decision in Montreal before the San Diego meeting. In the meanwile, in light of the number of changes, here is an update. This draft has been completely re-written in light of the=20 decisions made in Montreal, and in light of what follows from these decisions. The key changes are as follows: - Clarification of the meaning of SIPS, i.e., implies transitive trust. - Clarification of the justification for the "last-hop exception rule". It does NOT mean that the terminating side may not support TLS (for example, for its own outbound requests).=20 - SIP-outbound and Record-Route are required for enabling support of SIPS in practical deployments. - SIP routing is independent of the scheme in the AOR and the transport. It is the association of a AOR to a particular Contact in a Registration that will determined if a request is routable with SIPS. This caused a=20 complete rewrite of the Registration section. The good news is that after going through this significant rewrite of the=20 draft, with the new assumptions on routing, I believe that RFC 3261 is not really as "broken" as initially tought (but it is indeed "underspecified").=20 The drafts highlights a few nit-picks, but broadly, I think that we can say=20 that SIPS is implementable without significant normative changes to RFC 3261. Please review and provide feedback. ------_=_NextPart_001_01C6C6FE.97FF3AEB Content-Type: application/octet-stream; name="draft-audet-sip-sips-guidelines-03.URL" Content-Transfer-Encoding: base64 Content-Description: draft-audet-sip-sips-guidelines-03.URL Content-Disposition: attachment; filename="draft-audet-sip-sips-guidelines-03.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1hdWRldC1zaXAtc2lwcy1ndWlkZWxpbmVzLTAzLnR4dA0K ------_=_NextPart_001_01C6C6FE.97FF3AEB Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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_01C6C6FE.97FF3AEB-- From sip-bounces@ietf.org Wed Aug 23 18:15:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0xN-0006Rk-PY; Wed, 23 Aug 2006 18:12:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0xN-0006RT-6b for sip@ietf.org; Wed, 23 Aug 2006 18:12:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG0xN-000158-51 for sip@ietf.org; Wed, 23 Aug 2006 18:12:17 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GG0rW-0007us-4C for sip@ietf.org; Wed, 23 Aug 2006 18:06:16 -0400 Received: from [192.168.0.66] (81-178-58-134.dsl.pipex.com [81.178.58.134]) by astro.systems.pipex.net (Postfix) with ESMTP id F14F3E0000D5 for ; Wed, 23 Aug 2006 23:06:12 +0100 (BST) Message-ID: <44ECD134.50603@pjsip.org> Date: Wed, 23 Aug 2006 23:05:40 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Sip] Comments for connect-reuse-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Vijay, I also want to share my comments after reading the connect-reuse-6 draft. This is the first time I read the document and involved in the discussion, so please bear with me if what I'm saying doesn't make any sense. My .02p below. - Alias table I understand that servers need to maintain the aliased transports in the alias table; this is the basic operation for connect-reuse. But what I don't understand is, why clients MUST add (aliased) outgoing connection to the alias table. Isn't it sufficient to just put the transport into the "normal" transport table? - Server handling multiple alias I think it's important to define actions to be taken by servers when receiving multiple incoming connections that resolve to the same alias entry. I can think of several options: 1. delete old alias with new alias, and gracefully close old connection, or 2. reject the new connection, or 3. load balance the connections, or 4. please contact administrator (my favorite) - Page 7: "When the server, P2, receives the request, it may add a "received" parameter to the topmost Via..." In the context of Via header being discussed, I think the server *will* (or MUST) add "received" parameter to the topmost Via, since the Via sent-by is not an IP address. - Page 10: "Clients must be prepared for the case that the connection no longer exists when they are ready to send a subsequent request over it. This may happen if the peer ran out of operating system resources and had to close the connection." This sounds like servers only close connection on an exceptional conditions, and certainly is not the case. If the server doesn't honor the "alias" request, or if it doesn't support it, then the connection will be closed normally as per RFC 3261 procedure. - Page 13: (nit) "Once the malware program decides that a legitimate user agent is not running, it sends sends.." (note the double sends) My 0.2p. -benny _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 24 10:37:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGGGy-00008E-3H; Thu, 24 Aug 2006 10:33:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGGGx-00007o-5e; Thu, 24 Aug 2006 10:33:31 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGGGu-0000R8-G9; Thu, 24 Aug 2006 10:33:31 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k7OEXOov021236; Thu, 24 Aug 2006 09:33:24 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Aug 2006 09:33:24 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Aug 2006 16:33:22 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have anHTTPdereferencemechanism defined Date: Thu, 24 Aug 2006 16:33:22 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918030B2E8@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [Geopriv] Does Location-Conveyance have anHTTPdereferencemechanism defined Thread-Index: Aca1B+ZeLLsjYFmHQQ2U8yRlbuTwXgAIJqCAAtvtv1AAHNzGYAGdm0Lw From: "Drage, Keith \(Keith\)" To: "Dawson, Martin" , "Andrew Newton" , "Winterbottom, James" X-OriginalArrivalTime: 24 Aug 2006 14:33:22.0456 (UTC) FILETIME=[4048B980:01C6C78A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: IETF SIP List , "Rosen, Brian" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So in order to complete, we therefore need a new GEOPRIV draft that defines the list of dereferencing protocols, and which location conveyance will normatively reference? Regards Keith=20 > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > Sent: 16 August 2006 09:25 > To: Drage, Keith (Keith); Andrew Newton; Winterbottom, James > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance=20 > have anHTTPdereferencemechanism defined >=20 > Hi Keith, >=20 > 1. I disagree that a HTTP URI indicates anything about the=20 > using protocol other than the transport it uses. HTTP is the=20 > transport. A SIP URI could equally indicate a SIP transport=20 > but with a set of protocol semantics that do not honor the=20 > geopriv requirements. >=20 > 2. No - as above - the reference URI does not convey=20 > information about the nature of the user protocol that the=20 > referenced server is going to support. Also, even if the URI=20 > did indicate the nature of the using protocol, it is not=20 > appropriate to have to continually update a SIP document=20 > every time a new geopriv compliant user protocol is invented. > The SIP conveyance cannot assure anything about the integrity=20 > of the using protocol supported by the referenced server and=20 > it should not imply that it can. Services that are provided=20 > for the purpose of location object conveyance will need to be=20 > assessed themselves as to whether they meet the geopriv constraints. >=20 > 3. I think geopriv could maintain a document of *actual using=20 > protocols* that are considered to meet the geopriv=20 > constraints. Noting that listing the actual protocols also=20 > conveys more than the type of URI that could be used to=20 > reference a server supporting those protocols. At least,=20 > then, there would be a single place to maintain this=20 > information and the SIP specification can simply state that=20 > the URI, whatever its form, must be a reference to a server=20 > which supports a using protocol that honors geopriv=20 > constraints - as could every one of the other protocols that=20 > I would certainly hope are going to be able to convey a=20 > location reference > - and without having to be updated every time a new using=20 > protocol is defined. >=20 > Cheers, > Martin >=20 > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Wednesday, 16 August 2006 4:32 AM > > To: Dawson, Martin; Andrew Newton; Winterbottom, James > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have=20 > > anHTTPdereferencemechanism defined > >=20 > > I must admit I am still having trouble working out what=20 > your position,=20 > > and that of Henning and James W. is. > >=20 > > 1) The dereferencing protocol is a using protocol according to the > > GEOPRIV RFCs. I assume that GEOPRIV is therefore going to=20 > require that=20 > > such a using protocol meets their requirements. HTTP in its current > form > > does not meet those requirements. Is there anything here=20 > you disagree=20 > > with? > >=20 > > 2) So then we get to the step of should the URI conveyance police > > the using protocol that can be used, which is essentially what Brian > is > > proposing. I certainly understand that it should be policed=20 > somewhere,=20 > > and if it is not policed by the syntax of the protocol, it=20 > either has > to > > be policed by the dereferencer, or by the location provider itself. > > Where do you stand on this? To me it seems automatic to police it by > the > > types of URI that are allowed to be used, and therefore I need to=20 > > understand how you see this. > >=20 > > 3) If you agree that we police by the types of URI to be used, is > > the problem here then that GEOPRIV rather than SIP should write the=20 > > document that makes these constraints? > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: 01 August 2006 06:14 > > > To: Andrew Newton; Winterbottom, James > > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have=20 > > > anHTTPdereferencemechanism defined > > > > > > I'm OK as long as the ABNF includes the AbsoluteURI=20 > option and the=20 > > > text does not say anything specifically about excluding=20 > HTTP (or any=20 > > > other form of URI). > > > > > > I've attempted to point out previously that the URI=20 > doesn't actually=20 > > > convey anything about whether the geopriv rules are going to be=20 > > > respected or not. It's actually a geopriv rule that those=20 > rules be=20 > > > respected so it's superfluous, and out of scope, to also=20 > require the=20 > > > statement in a SIP conveyance document. > > > > > > AbsoluteURI as a generic form, encompasses sip etc.=20 > anyway, so it's=20 > > > also superfluous to include those in the ABNF. > > > However, it's also a harmless waste of space. If Brian is keen to=20 > > > include them for some reason, and as long as neither the text nor=20 > > > the ABNF bias the specification toward those forms in any=20 > way, then=20 > > > there are certainly better things to lose sleep over. > > > > > > Cheers, > > > Martin > > > > > > > -----Original Message----- > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > Sent: Tuesday, 1 August 2006 11:15 AM > > > > To: Winterbottom, James > > > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > > > Subject: Re: [Sip] RE: [Geopriv] Does=20 > Location-Conveyance have an=20 > > > > HTTPdereferencemechanism defined > > > > > > > > > > > > On Jul 31, 2006, at 9:11 PM, Winterbottom, James wrote: > > > > > > > > > Hi Andy, > > > > > > > > > > That is all I have asked for, do not constrain the ABNF. > > > If "how I > > > > > use HTTP as a reference" goes in a different document > > > that is fine > > > > > providing the ABNF is not constrained in the conveyance=20 > > > > > specification. This is not how I read Brian's statement below: > > > > > > > > > > "This is NOT the discussion of what the ABNF of the > > > location header > > > > > looks like (although it would NOT have http/https in it > > > for sure if > > > > > we > > > agree > > > > > that an HTTP dereference protocol is a separate draft)." > > > > > > > > > > Which to me clearly says the ABNF will be restrict to > > > exclude HTTP/ > > > > > HTTPS if there is agreement that the conveyance draft > > > doesn't have > > > > > specific text on how to deference an HTTP reference. > > > > > > > > > > Cheers > > > > > James > > > > > > > > Please keep in mind that this does not stop the draft from > > > using MUST/ > > > > SHOULD language from stipulating "the URI MUST be a GEOPRIV > > > standards > > > > track using protocol." > > > > > > > > -andy > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > -------------------------------------------------------------- > > > ---------------------------------- > > > This message is for the designated recipient only and may contain=20 > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender=20 > > > immediately and delete the original. Any unauthorized=20 > use of this=20 > > > email is prohibited. > > > -------------------------------------------------------------- > > > ---------------------------------- > > > [mf2] > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 24 13:04:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIZx-0007N9-Iw; Thu, 24 Aug 2006 13:01:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIZw-0007Mw-AP for sip@ietf.org; Thu, 24 Aug 2006 13:01:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGI6m-0004XQ-Q5 for sip@ietf.org; Thu, 24 Aug 2006 12:31:08 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGI0H-0008Ok-1Y for sip@ietf.org; Thu, 24 Aug 2006 12:24:27 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k7OGOG0L013544; Thu, 24 Aug 2006 11:24:16 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k7OGOFL29441; Thu, 24 Aug 2006 11:24:15 -0500 (CDT) Message-ID: <44EDD2AF.90709@lucent.com> Date: Thu, 24 Aug 2006 11:24:15 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [Sip] Comments for connect-reuse-06 References: <44ECD134.50603@pjsip.org> In-Reply-To: <44ECD134.50603@pjsip.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Benny Prijono wrote: > Hi Vijay, > > I also want to share my comments after reading the connect-reuse-6 > draft. This is the first time I read the document and involved in the > discussion, so please bear with me if what I'm saying doesn't make any > sense. Benny: Thank you for your time and willingness to read the document. More inline. > My .02p below. > > - Alias table > I understand that servers need to maintain the aliased transports in > the alias table; this is the basic operation for connect-reuse. But what > I don't understand is, why clients MUST add (aliased) outgoing > connection to the alias table. Isn't it sufficient to just put the > transport into the "normal" transport table? Sure; if you already have one. > - Server handling multiple alias > I think it's important to define actions to be taken by servers when > receiving multiple incoming connections that resolve to the same alias > entry. I can think of several options: > 1. delete old alias with new alias, and gracefully close old > connection, or > 2. reject the new connection, or > 3. load balance the connections, or > 4. please contact administrator (my favorite) I'd actually like to hear some more views on this. Some folks have suggested (3), which is on the complex end of the spectrum (how many connections is enough? What is the load balancing scheme? etc.) (1) and (2) are possibly good candidates as well. (4) is out of the question, I think. What do folks think? > - Page 7: "When the server, P2, receives the request, it may add a > "received" parameter to the topmost Via..." > In the context of Via header being discussed, I think the server > *will* (or MUST) add "received" parameter to the topmost Via, since the > Via sent-by is not an IP address. Right ... that's a rfc3261 stipulation, and no need to hedge around it. I re-worded the paragraph to now read: When the server, P2, receives the request, it examines the topmost Via to determine whether P1 supports aliased connections. The Via at P2 now looks like (the "received" parameter is added by P2):
> - Page 10: > "Clients must be prepared for the case that the connection no longer > exists when they are ready to send a subsequent request over it. > This may happen if the peer ran out of operating system resources and > had to close the connection." > > This sounds like servers only close connection on an exceptional > conditions, and certainly is not the case. If the server doesn't honor > the "alias" request, or if it doesn't support it, then the connection > will be closed normally as per RFC 3261 procedure. True ... but the text you quote is referring to the fact that the client had previously established an aliased connection, but much later it got reclaimed. I think the paragraph right before the one you quote contains the gist of your comment above. > - Page 13: (nit) > "Once the malware program decides that a legitimate user agent is not > running, it sends sends.." > (note the double sends) Fixed. Thanks a bunch for your time on this. Ciao. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 24 14:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGK8W-0000Zo-Dx; Thu, 24 Aug 2006 14:41:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGK8U-0000Zf-Jp for sip@ietf.org; Thu, 24 Aug 2006 14:41:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGK8U-0001x3-HY for sip@ietf.org; Thu, 24 Aug 2006 14:41:02 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGK8S-0003P0-8Q for sip@ietf.org; Thu, 24 Aug 2006 14:41:02 -0400 Received: from [192.168.0.66] (81-178-58-134.dsl.pipex.com [81.178.58.134]) by blaster.systems.pipex.net (Postfix) with ESMTP id 230BCE00022C; Thu, 24 Aug 2006 19:40:48 +0100 (BST) Message-ID: <44EDF2A3.4010209@pjsip.org> Date: Thu, 24 Aug 2006 19:40:35 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] Comments for connect-reuse-06 References: <44ECD134.50603@pjsip.org> <44EDD2AF.90709@lucent.com> In-Reply-To: <44EDD2AF.90709@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Vijay, thanks for the reply. More below. Vijay K. Gurbani wrote: >> - Alias table >> I understand that servers need to maintain the aliased transports in >> the alias table; this is the basic operation for connect-reuse. But >> what I don't understand is, why clients MUST add (aliased) outgoing >> connection to the alias table. Isn't it sufficient to just put the >> transport into the "normal" transport table? > > Sure; if you already have one. Sorry I don't get you, which one? Transport table? Alias table? Or are they basically the same thing? So what is alias table? I think my confusion was caused from reading page 6 (in the bottom) that says: "To aid in connection reuse, a new data structure, the connection alias table (or simply, alias table) is defined in this document and is used to store the resolved addresses." As implementor, I'm quite familiar with the term transport table (or transport hash table, transport map, etc.), because this is a logical consequences of having transport layer in a SIP stack. So reading the paragraph, I thought the document suggests that a new table should be created. Since I suspect this isn't the case, perhaps we can change the wordings to something like: "To aid the discussion of connection reuse, this document defines a data structure called connection alias table (or simply, alias table) which is used to store aliased addresses. User agent can.." >> - Server handling multiple alias >> I think it's important to define actions to be taken by servers when >> receiving multiple incoming connections that resolve to the same alias >> entry. I can think of several options: >> 1. delete old alias with new alias, and gracefully close old >> connection, or >> 2. reject the new connection, or >> 3. load balance the connections, or >> 4. please contact administrator (my favorite) > > I'd actually like to hear some more views on this. Some folks > have suggested (3), which is on the complex end of the spectrum > (how many connections is enough? What is the load balancing > scheme? etc.) (1) and (2) are possibly good candidates as well. > (4) is out of the question, I think. > > What do folks think? I'll let others comment on this. >> - Page 7: "When the server, P2, receives the request, it may add a >> "received" parameter to the topmost Via..." >> In the context of Via header being discussed, I think the server >> *will* (or MUST) add "received" parameter to the topmost Via, since >> the Via sent-by is not an IP address. > > Right ... that's a rfc3261 stipulation, and no need to hedge around > it. I re-worded the paragraph to now read: > > When the server, P2, receives the request, it examines the > topmost Via to determine whether P1 supports aliased connections. > The Via at P2 now looks like (the "received" parameter is added > by P2): Perfect. > >> - Page 10: >> "Clients must be prepared for the case that the connection no longer >> exists when they are ready to send a subsequent request over it. >> This may happen if the peer ran out of operating system resources and >> had to close the connection." >> >> This sounds like servers only close connection on an exceptional >> conditions, and certainly is not the case. If the server doesn't honor >> the "alias" request, or if it doesn't support it, then the connection >> will be closed normally as per RFC 3261 procedure. > > True ... but the text you quote is referring to the fact that the > client had previously established an aliased connection, but much > later it got reclaimed. I think the paragraph right before the > one you quote contains the gist of your comment above. No, there's nothing there that says "much later", and even if there was, it wouldn't make any difference. I would suggest that we just delete the "This may happen if the peer ran out of operating system resources and had to close the connection" bit, since the previous paragraph has made it clear that connection (aliased or not) may be closed by server anyway. thanks, -benny _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 24 15:17:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGKfi-000501-Hg; Thu, 24 Aug 2006 15:15:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGKfh-0004zs-92; Thu, 24 Aug 2006 15:15:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGKff-00008c-I2; Thu, 24 Aug 2006 15:15:21 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 24 Aug 2006 12:15:19 -0700 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.20060308/8.12.11) with ESMTP id k7OJFI8Y010350; Thu, 24 Aug 2006 12:15:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7OJFGQV011961; Thu, 24 Aug 2006 12:15:16 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 12:15:16 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.121.92]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 12:15:15 -0700 Message-Id: <4.3.2.7.2.20060824141440.03c5e590@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Aug 2006 14:15:15 -0500 To: "Drage, Keith \(Keith\)" , "Dawson, Martin" , "Andrew Newton" , "Winterbottom, James" From: "James M. Polk" Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have anHTTPdereferencemechanism defined In-Reply-To: <5D1A7985295922448D5550C94DE2918030B2E8@DEEXC1U01.de.lucent .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 24 Aug 2006 19:15:15.0756 (UTC) FILETIME=[A1657EC0:01C6C7B1] DKIM-Signature: a=rsa-sha1; q=dns; l=8941; t=1156446919; x=1157310919; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Sip]=20RE=3A=20[Geopriv]=20Does=20Location-Conveyance=20have=0A =20=20anHTTPdereferencemechanism=20defined; X=v=3Dcisco.com=3B=20h=3DZBJGE+4RxO/qXwPnur5UNa5YyUw=3D; b=Wq9nWSiKj6ZDM/aMs7LXNFsffIY0vK+hMfyxV4YN3E+tff3o06MbEbq+UUwxZfJGC/409Sjq A//Skbvpojj6gyoQqx3FfUtNUReScXLD+tBy7iNz8wOoUI1yimAzo89Q; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: IETF SIP List , "Rosen, Brian" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 04:33 PM 8/24/2006 +0200, Drage, Keith \(Keith\) wrote: >So in order to complete, we therefore need a new GEOPRIV draft that >defines the list of dereferencing protocols, and which location >conveyance will normatively reference? god I hope not.... : ( >Regards > >Keith > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: 16 August 2006 09:25 > > To: Drage, Keith (Keith); Andrew Newton; Winterbottom, James > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance > > have anHTTPdereferencemechanism defined > > > > Hi Keith, > > > > 1. I disagree that a HTTP URI indicates anything about the > > using protocol other than the transport it uses. HTTP is the > > transport. A SIP URI could equally indicate a SIP transport > > but with a set of protocol semantics that do not honor the > > geopriv requirements. > > > > 2. No - as above - the reference URI does not convey > > information about the nature of the user protocol that the > > referenced server is going to support. Also, even if the URI > > did indicate the nature of the using protocol, it is not > > appropriate to have to continually update a SIP document > > every time a new geopriv compliant user protocol is invented. > > The SIP conveyance cannot assure anything about the integrity > > of the using protocol supported by the referenced server and > > it should not imply that it can. Services that are provided > > for the purpose of location object conveyance will need to be > > assessed themselves as to whether they meet the geopriv constraints. > > > > 3. I think geopriv could maintain a document of *actual using > > protocols* that are considered to meet the geopriv > > constraints. Noting that listing the actual protocols also > > conveys more than the type of URI that could be used to > > reference a server supporting those protocols. At least, > > then, there would be a single place to maintain this > > information and the SIP specification can simply state that > > the URI, whatever its form, must be a reference to a server > > which supports a using protocol that honors geopriv > > constraints - as could every one of the other protocols that > > I would certainly hope are going to be able to convey a > > location reference > > - and without having to be updated every time a new using > > protocol is defined. > > > > Cheers, > > Martin > > > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: Wednesday, 16 August 2006 4:32 AM > > > To: Dawson, Martin; Andrew Newton; Winterbottom, James > > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have > > > anHTTPdereferencemechanism defined > > > > > > I must admit I am still having trouble working out what > > your position, > > > and that of Henning and James W. is. > > > > > > 1) The dereferencing protocol is a using protocol according to the > > > GEOPRIV RFCs. I assume that GEOPRIV is therefore going to > > require that > > > such a using protocol meets their requirements. HTTP in its current > > form > > > does not meet those requirements. Is there anything here > > you disagree > > > with? > > > > > > 2) So then we get to the step of should the URI conveyance police > > > the using protocol that can be used, which is essentially what Brian > > is > > > proposing. I certainly understand that it should be policed > > somewhere, > > > and if it is not policed by the syntax of the protocol, it > > either has > > to > > > be policed by the dereferencer, or by the location provider itself. > > > Where do you stand on this? To me it seems automatic to police it by > > the > > > types of URI that are allowed to be used, and therefore I need to > > > understand how you see this. > > > > > > 3) If you agree that we police by the types of URI to be used, is > > > the problem here then that GEOPRIV rather than SIP should write the > > > document that makes these constraints? > > > > > > Regards > > > > > > Keith > > > > > > > > > > > > > -----Original Message----- > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > Sent: 01 August 2006 06:14 > > > > To: Andrew Newton; Winterbottom, James > > > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > > > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have > > > > anHTTPdereferencemechanism defined > > > > > > > > I'm OK as long as the ABNF includes the AbsoluteURI > > option and the > > > > text does not say anything specifically about excluding > > HTTP (or any > > > > other form of URI). > > > > > > > > I've attempted to point out previously that the URI > > doesn't actually > > > > convey anything about whether the geopriv rules are going to be > > > > respected or not. It's actually a geopriv rule that those > > rules be > > > > respected so it's superfluous, and out of scope, to also > > require the > > > > statement in a SIP conveyance document. > > > > > > > > AbsoluteURI as a generic form, encompasses sip etc. > > anyway, so it's > > > > also superfluous to include those in the ABNF. > > > > However, it's also a harmless waste of space. If Brian is keen to > > > > include them for some reason, and as long as neither the text nor > > > > the ABNF bias the specification toward those forms in any > > way, then > > > > there are certainly better things to lose sleep over. > > > > > > > > Cheers, > > > > Martin > > > > > > > > > -----Original Message----- > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > Sent: Tuesday, 1 August 2006 11:15 AM > > > > > To: Winterbottom, James > > > > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > > > > Subject: Re: [Sip] RE: [Geopriv] Does > > Location-Conveyance have an > > > > > HTTPdereferencemechanism defined > > > > > > > > > > > > > > > On Jul 31, 2006, at 9:11 PM, Winterbottom, James wrote: > > > > > > > > > > > Hi Andy, > > > > > > > > > > > > That is all I have asked for, do not constrain the ABNF. > > > > If "how I > > > > > > use HTTP as a reference" goes in a different document > > > > that is fine > > > > > > providing the ABNF is not constrained in the conveyance > > > > > > specification. This is not how I read Brian's statement below: > > > > > > > > > > > > "This is NOT the discussion of what the ABNF of the > > > > location header > > > > > > looks like (although it would NOT have http/https in it > > > > for sure if > > > > > > we > > > > agree > > > > > > that an HTTP dereference protocol is a separate draft)." > > > > > > > > > > > > Which to me clearly says the ABNF will be restrict to > > > > exclude HTTP/ > > > > > > HTTPS if there is agreement that the conveyance draft > > > > doesn't have > > > > > > specific text on how to deference an HTTP reference. > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > Please keep in mind that this does not stop the draft from > > > > using MUST/ > > > > > SHOULD language from stipulating "the URI MUST be a GEOPRIV > > > > standards > > > > > track using protocol." > > > > > > > > > > -andy > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > -------------------------------------------------------------- > > > > ---------------------------------- > > > > This message is for the designated recipient only and may contain > > > > privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized > > use of this > > > > email is prohibited. > > > > -------------------------------------------------------------- > > > > ---------------------------------- > > > > [mf2] > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 24 16:14:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLYG-0000IJ-6s; Thu, 24 Aug 2006 16:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLYE-0000Hf-DV for sip@ietf.org; Thu, 24 Aug 2006 16:11:42 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGLYD-0007AU-5M for sip@ietf.org; Thu, 24 Aug 2006 16:11:42 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A7F4032C; Thu, 24 Aug 2006 16:11:32 -0400 From: "Hadriel Kaplan" To: "'SIP'" Date: Thu, 24 Aug 2006 16:11:32 -0400 Message-ID: <07fe01c6c7b9$7dee3c40$6601a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0C834F94@zrc2hxm0.corp.nortel.com> Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQAAez0gA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] comments on draft-audet-sip-sips-guidelines-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Minor comments: Section 4 discusses "upgrades" and "downgrades", which is good because 3261 is ambiguous about it. Not a big deal, but I think you should specify who can do upgrading. Obviously the UAC can decide to "upgrade" by just trying a sips URI. But if some proxy tries upgrading, and it fails, the UAC has no way to make the proxy not try upgrading again the next time. A proxy should not just try without some reasonable foreknowledge of success? (e.g., a location service has such foreknowledge) Also, does the (old) exception rule really mean downgrading, i.e. replacing the req-URI with a SIP of the registered contact? Or does it mean the req-URI is still SIPS but the message is simply sent over non-TLS to the UAS? Section 3 last sentence says one may use Identity instead of or with sips, implying identity is end-to-end. It's not. It's essentially domain-to-domain or domain-to-end, IMO. The signing proxy or something before it can (and I'm fairly confident will in some cases) change things. Section 3, page 5 says if a SIPS Request-URI was used, then the UAS would have to support SIPS to generate a Bye, unless Record-Route is used. Why would a Record-Route solve that problem? Per 3261 the Record-Route would also have to be a SIPS URI, no? Editorial but important: Sec 3, page 5: "This means that b@B, upon sending a new Request (e.g., a BYE), will have to use a SIP URI (unless Record-Route is used)." I assume you meant SIPS. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 24 16:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLeJ-0004ix-42; Thu, 24 Aug 2006 16:17:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLeH-0004is-Mi for sip@ietf.org; Thu, 24 Aug 2006 16:17:57 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGLeE-00085v-Bw for sip@ietf.org; Thu, 24 Aug 2006 16:17:57 -0400 Received: from [64.101.149.121] (gmatulka-w2k01.cisco.com [64.101.149.121]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7OKKDIx028532 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 24 Aug 2006 15:20:14 -0500 In-Reply-To: <07fe01c6c7b9$7dee3c40$6601a8c0@acmepacket.com> References: <07fe01c6c7b9$7dee3c40$6601a8c0@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7ED311FC-3C75-44AF-B706-AC4897C377B7@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] comments on draft-audet-sip-sips-guidelines-03.txt Date: Thu, 24 Aug 2006 15:17:30 -0500 To: "Hadriel Kaplan" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'SIP' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 24, 2006, at 3:11 PM, Hadriel Kaplan wrote: > > Also, does the (old) exception rule really mean downgrading, i.e. > replacing > the req-URI with a SIP of the registered contact? Or does it mean the > req-URI is still SIPS but the message is simply sent over non-TLS > to the > UAS? > I'd really like to fix SIP so that contact-routing operations just add routes instead of replacing the request-URI. That would make several things much nicer. -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 24 18:18:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNU2-0005D9-BG; Thu, 24 Aug 2006 18:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNU0-00059i-6Q for sip@ietf.org; Thu, 24 Aug 2006 18:15:28 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGNTy-000415-TR for sip@ietf.org; Thu, 24 Aug 2006 18:15:28 -0400 Received: from [192.168.0.66] (81-178-58-134.dsl.pipex.com [81.178.58.134]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 5CC67E000309; Thu, 24 Aug 2006 23:15:24 +0100 (BST) Message-ID: <44EE24FB.1070402@pjsip.org> Date: Thu, 24 Aug 2006 23:15:23 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] Comments for connect-reuse-06 References: <44ECD134.50603@pjsip.org> <44EDD2AF.90709@lucent.com> <44EDF2A3.4010209@pjsip.org> <44EDF74B.6070706@lucent.com> In-Reply-To: <44EDF74B.6070706@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > How about this: I modify the paragraph in question as follows: > > OLD: > Clients must be prepared for the case that the connection no longer > exists when they are ready to send a subsequent request over it. > This may happen if the peer ran out of operating system resources and > had to close the connection. > > NEW: > Once an alias has been established, clients must be prepared > for the case that the connection no longer exists when they > are ready to send a subsequent request over it. I don't have any problem with this part, and in fact, the old sentence is okay too (if not better). > This could happen if the server ran out of operating system resources and > had to reclaim the connection. > Now, this is the part of the paragraph that I'm protesting against. If you want to explain why connection is closed in the client side, then I believe the complete sentence should look like this: This could happen if server does not support connection reuse, or when the server decides that it doesn't want to honor connection reuse request (perhaps because there is already an alias that resolves to the same client), or when the server decides to drop the connection (perhaps because it receives another connection that resolves to the same client), or because it runs out of operating system resources. So either we put the complete sentence like that, or we just delete the sentence altogether. I was proposing that we just delete it, since the behavior has been explained elsewhere. Of course I might just be missing something here. -benny _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 24 19:30:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGObm-0003TC-2S; Thu, 24 Aug 2006 19:27:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGObk-0003T6-VD for sip@ietf.org; Thu, 24 Aug 2006 19:27:32 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGObi-0002iS-LJ for sip@ietf.org; Thu, 24 Aug 2006 19:27:32 -0400 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 k7ONRRo17551; Thu, 24 Aug 2006 19:27:28 -0400 (EDT) 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 Subject: RE: [Sip] comments on draft-audet-sip-sips-guidelines-03.txt Date: Thu, 24 Aug 2006 18:27:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0C8E1B80@zrc2hxm0.corp.nortel.com> In-Reply-To: <07fe01c6c7b9$7dee3c40$6601a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-audet-sip-sips-guidelines-03.txt Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQAAez0gAAM0Aw0A== From: "Francois Audet" To: "Hadriel Kaplan" , "SIP" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > Minor comments: >=20 > Section 4 discusses "upgrades" and "downgrades", which is=20 > good because 3261 is ambiguous about it. Not a big deal, but=20 > I think you should specify who can do upgrading. Obviously=20 > the UAC can decide to "upgrade" by just trying a sips URI. =20 > But if some proxy tries upgrading, and it fails, the UAC has=20 > no way to make the proxy not try upgrading again the next=20 > time. A proxy should not just try without some reasonable=20 > foreknowledge of success? (e.g., a location service has such=20 > foreknowledge) Agree. I need to ask some wording to this effect. Basically, a proxy "upgrades" from SIP to SIPS when it has legitimate reasons to do do. For example, if the binding associated with the AOR is a SIPS Contact, it would=20 "upgrade" the Request-URI to a sips URI. This is illustrated in message F13 in section 10.2. > Also, does the (old) exception rule really mean downgrading,=20 > i.e. replacing the req-URI with a SIP of the registered=20 > contact? Or does it mean the req-URI is still SIPS but the=20 > message is simply sent over non-TLS to the UAS? I would say that the Request-URI would be sent to whatever contact was used in Registration for the last hop, i.e., to the sip URI. > Section 3 last sentence says one may use Identity instead of=20 > or with sips, implying identity is end-to-end. It's not. =20 > It's essentially domain-to-domain or domain-to-end, IMO. The=20 > signing proxy or something before it can (and I'm fairly=20 > confident will in some cases) change things. You are correct. I will make the change. > Section 3, page 5 says if a SIPS Request-URI was used, then=20 > the UAS would have to support SIPS to generate a Bye, unless=20 > Record-Route is used. Why would a Record-Route solve that=20 > problem? Per 3261 the Record-Route would also have to be a=20 > SIPS URI, no? You are correct: brain fart on my part. I was thinking of something else. I'll remove the "(unless Record-Route is used)". =20 > Editorial but important: > Sec 3, page 5: "This means that b@B, upon sending a new=20 > Request (e.g., a BYE), will have to use a SIP URI (unless=20 > Record-Route is used)." I assume you meant SIPS. Oops. My bad. Yes, it will be fixed. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 05:10:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGXeV-0007jk-EN; Fri, 25 Aug 2006 05:06:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGXeS-0007eX-IM for sip@ietf.org; Fri, 25 Aug 2006 05:06:57 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGXeR-0003ih-7N for sip@ietf.org; Fri, 25 Aug 2006 05:06:56 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 11:06:48 +0200 Received: from L-AT7568 ([10.193.5.47]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 11:06:48 +0200 Date: Fri, 25 Aug 2006 11:07:20 +0200 From: "Xavier Marjou" To: sip@ietf.org Subject: Re: [Sip] GRUU and Mid-Dialog Requests Message-ID: X-Mailer: JBMail 3.2 X-OriginalArrivalTime: 25 Aug 2006 09:06:48.0633 (UTC) FILETIME=[CBDE5A90:01C6C825] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm still not 100% convinced that extending the scope of the remote target (ie: Contact header field) to carry a gruu URI is necessary. What about the following alternative mechanism: - UA X obtains a GRUU AOR (eg: sip:ua-x;gruu=xyz) either by a response to a REGISTER request or by an external means. - UA X must register his GRUU AOR before using it (as it recognize a gruu aor, the registrar only accepts one address-of-contact, so that forking towards multiple contacts is not possible) - UA X can then use its GRUU AOR in its From header when sending an "initial" request, or substitute his AOR with its GRUU AOR in the To header when receiving an "initial" request. In this case, mid-dialog requests are not impacted. Moreover the anonymous property of the GRUU AOR may be left out of the GRUU spec, as it comes back to the general usage in From and To headers. Xavier _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 07:52:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGaBE-0003Bo-2o; Fri, 25 Aug 2006 07:48:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGaBB-0003Aa-UA for Sip@ietf.org; Fri, 25 Aug 2006 07:48:53 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGaB6-0005Xk-Fa for Sip@ietf.org; Fri, 25 Aug 2006 07:48:53 -0400 Received: from bemail02.netfr.alcatel.fr (bemail02.netfr.alcatel.fr [155.132.251.36]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PBmlox007651 for ; Fri, 25 Aug 2006 13:48:48 +0200 Received: from [138.203.251.40] ([138.203.251.40]) by bemail02.netfr.alcatel.fr (Lotus Domino Release 6.5.4FP2HF315) with ESMTP id 2006082513484556-8678 ; Fri, 25 Aug 2006 13:48:45 +0200 Message-ID: <44EEE39C.3050504@alcatel.be> Date: Fri, 25 Aug 2006 13:48:44 +0200 From: olivier.ro.rousseau@alcatel.be Organization: Alcatel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sip@ietf.org X-MIMETrack: Itemize by SMTP Server on BEMAIL02/BE/ALCATEL(Release 6.5.4FP2HF315 | February 22, 2006) at 08/25/2006 13:48:45, Serialize by Router on BEMAIL02/BE/ALCATEL(Release 6.5.4FP2HF315 | February 22, 2006) at 08/25/2006 13:48:46, Serialize complete at 08/25/2006 13:48:46 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Sip] question about RFC4240 (NETANN) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, I have a problem with the RFC 4240. The language parameter is defined in the page 10. locale-param = "locale=" token ; per RFC 3066, usually ; ISO639-1_ISO3166-1 ; e.g., en, en_US, en_UK, etc. and is explained in page 7 locale Specifies the language and optionally country variant of the announcement sequence named in the "play=" parameter. RFC 3066 [9] specifies the locale tag. The locale tag is usually a two- or three-letter code per ISO 639-1 [11]. The country variant is also often a two-letter code per ISO 3166-1 [12]. These elements are concatenated with a single under bar (%x5F) character, such as "en_CA". However whe I look in the RFC3066 I found Language-Tag = Primary-subtag *( "-" Subtag ) Primary-subtag = 1*8ALPHA Subtag = 1*8(ALPHA / DIGIT) In the RFC3261, the Accept-Langugae is defined as Accept-Language = "Accept-Language" HCOLON [ language *(COMMA language) ] language = language-range *(SEMI accept-param) language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) You can see that one RFC says that a "_" must be used between the two subtags while the two others says that it must be a "-". And worse the RFC4240 refers to RFC3066 but uses a different syntax in its BNF and in its text ( Could someone clarify what I should use? Thanks and regards, Olivier _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 10:31:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGcfc-0000OT-AM; Fri, 25 Aug 2006 10:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGcfa-0000OO-Lf for sip@ietf.org; Fri, 25 Aug 2006 10:28:26 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGcfZ-0004kC-9n for sip@ietf.org; Fri, 25 Aug 2006 10:28:26 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 16:28:21 +0200 Received: from L-AT7568 ([10.193.5.47]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 16:28:21 +0200 Date: Fri, 25 Aug 2006 16:28:53 +0200 From: "Xavier Marjou" To: pkyzivat@cisco.com Subject: Re: [Sip] GRUU and Mid-Dialog Requests Message-ID: X-Mailer: JBMail 3.2 X-OriginalArrivalTime: 25 Aug 2006 14:28:21.0462 (UTC) FILETIME=[B74A6F60:01C6C852] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > That doesn't solve the use cases that GRUU was devised for. > The interesting cases are when UA X has registered at an AOR > (lets call it AOR-X) that has multiple registered contacts. > When UA X answers a dialog establishing request to AOR-X, > it needs to put something in the Contact address - something > that will route back to it. > I suppose, following your proposal, when it receives such a request > it could but its gruu into the Contact of the response. But in that > case we have all the same issues as the current proposal. Let's say UA X has a regular AOR (AOR-X), and 2 GRUU AOR (AOR-X;gruu=111 and AOR-X;gruu=222). When registering from device1, he both both AOR-X and AOR-X;gruu=111 When registering from device2, he both both AOR-X and AOR-X;gruu=222 When UA X answers a call on device1, it updates the addr in the "To" header with its GRUU AOR (AOR-X;gruu=111), but it does not modify the remote- target (Contact). Then the remote peer can use this GRUU-AOR to send a SUBSCRIBE for example. Of course, I know this breaks what has been envisioned for so far that is to advertise the GRUU in the remote-target. > So you are defining the term "GRUU AOR" to mean an AOR > that only accepts on registered contact. Yes, the idea would be to register the regular AOR from all devices (as usual many addr of contact are allowed) and to also regiter one derived AOR-GRUU per device (for each AOR-GRUU, only one addr of contact is allowed). > I think I must be missing something key in what you are proposing. > It seems like you are simply suggesting that all problems go away > if we never allow more than one contact to be registered with an AOR. I would certainly not pretend that "all the problems go away" for this complex topic ;-) I know I may not be aware of the whole story nor of all the possible impacts. Just consider it as an alternative I suggest to investigate. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 10:32:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGchn-0000nh-AU; Fri, 25 Aug 2006 10:30:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGchj-0000ht-Lc for sip@ietf.org; Fri, 25 Aug 2006 10:30:40 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGchi-0005RO-E6 for sip@ietf.org; Fri, 25 Aug 2006 10:30:39 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <20060825143037013008rlske>; Fri, 25 Aug 2006 14:30:37 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k7PEUbWI002966 for ; Fri, 25 Aug 2006 10:30:37 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k7PEUZmu002962; Fri, 25 Aug 2006 10:30:35 -0400 Date: Fri, 25 Aug 2006 10:30:35 -0400 Message-Id: <200608251430.k7PEUZmu002962@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (rjsparks@estacado.net) Subject: Re: [Sip] GRUU-10: Storing state at the binding-agent (GRUU-factory?) References: X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Robert Sparks A little later (page 15) it notes again that a UA MUST be prepared to receive a different GRUU for the same instance-id/AoR pair in subsequent registrations because this owning-thing might lose state. But, off in the appendix, in sections describing the creation of GRUUs it talks about building them such that this owning-thing doesn't have to create new state. Is there a real requirement to keep state here or not? I think the idea is to allow registrars a lot of latitude in how they create and handle GRUUs, as long as they produce effects that are generally what is desired. OTOH, the draft is careful to compel UAs to behave in ways that don't restrict how registrars can implement GRUUs. (E.g., being prepared for the GRUU to change, despite that the GRUU should never change.) Is it OK for me as a proxy that has the responsibility for retargeting GRUUs to _always_ return a 480 to a GRUU that I recognize as feasibly mine (cryptographically perhaps), maps correctly (whatever that means) to an AoR in good standing, but has no current registered contact associated with it EVEN IF I have no record of dealing with that particular instance-id ever before? I think it is. I've started looking at when to use which "address not found" error (404, 410, 480), and it's not clear to me that distinguishing between them can be done usefully: 1. Existing implementations are rather sloppy about which response code to return in various circumstances. 2. I've asked, and implementors do not have a strong and unified opinion about how the response codes are to be used. 3. The response code is generated in regard to the request-URI that the ultimate UAS sees, and in the context of the SIP domains that it is authoritative for (which will often be only its IP address). Thus, even if the UAS is exact in which response code it uses, it is in general impossible for the UAC to know what request-URI that response code describes. I think there is some value in restricting 480 to mean that the request arrived at a UAS that believes that it should handle the call, but due to some indication from the *user*, the user should not be notified at this time. This would be analogous to a 486. But this concept works because it takes 480 away from being a routing error, and turns it into a status indication for the UAS/user. Of course, this idea means that we need to change the error in the I-D mentioned by Robert above to something other than 480, one that specifically means "the AOR is valid but at this time we have no place to forward it to". I don't think that there is any code with that specific meaning now. OTOH, the assignment of response codes for error conditions has been sloppy in SIP from the very beginning, so there's no reason to start being careful now. Dale _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 10:40:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGcoS-0006WH-VI; Fri, 25 Aug 2006 10:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGcoR-0006Vo-If for sip@ietf.org; Fri, 25 Aug 2006 10:37:35 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGcoQ-0007Sc-9P for sip@ietf.org; Fri, 25 Aug 2006 10:37:35 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k7PEbU9P013133; Fri, 25 Aug 2006 09:37:30 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k7PEbTa01234; Fri, 25 Aug 2006 09:37:30 -0500 (CDT) Message-ID: <44EF0B2A.5040903@lucent.com> Date: Fri, 25 Aug 2006 09:37:30 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [Sip] Comments for connect-reuse-06 References: <44ECD134.50603@pjsip.org> <44EDD2AF.90709@lucent.com> <44EDF2A3.4010209@pjsip.org> <44EDF74B.6070706@lucent.com> <44EE24FB.1070402@pjsip.org> In-Reply-To: <44EE24FB.1070402@pjsip.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Benny Prijono wrote: > So either we put the complete sentence like that, or we just delete the > sentence altogether. I was proposing that we just delete it, since the > behavior has been explained elsewhere. Benny: OK, how about deleting it for the reason you list. So the text will look like: OLD: Clients must be prepared for the case that the connection no longer exists when they are ready to send a subsequent request over it. This may happen if the peer ran out of operating system resources and had to close the connection. In such a case, a new connection MUST be opened to the resolved address and the alias table updated accordingly. NEW: Once an alias has been established, clients must be prepared for the case that the connection no longer exists when they are ready to send a subsequent request over it. In such a case, a new connection MUST be opened to the resolved address and the alias table updated accordingly. I actually like the "Once an alias has been established" phrase. It provides some context that goes a bit beyond the paragraph that preceeds it. Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 10:42:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGcrr-0000Xk-W5; Fri, 25 Aug 2006 10:41:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGcrq-0000XN-0m for sip@ietf.org; Fri, 25 Aug 2006 10:41:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGbfo-0003w4-8e for sip@ietf.org; Fri, 25 Aug 2006 09:24:36 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGbIC-0003iD-LZ for sip@ietf.org; Fri, 25 Aug 2006 09:00:14 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Aug 2006 09:00:11 -0400 X-IronPort-AV: i="4.08,168,1154923200"; d="scan'208"; a="98691198:sNHT2834870598" 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.20060308/8.12.11) with ESMTP id k7PD0AKU031045; Fri, 25 Aug 2006 09:00:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7PD0AdM021224; Fri, 25 Aug 2006 09:00:10 -0400 (EDT) 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, 25 Aug 2006 09:00:10 -0400 Received: from [10.86.240.205] ([10.86.240.205]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 09:00:10 -0400 Message-ID: <44EEF459.5070906@cisco.com> Date: Fri, 25 Aug 2006 09:00:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Xavier Marjou Subject: Re: [Sip] GRUU and Mid-Dialog Requests References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 13:00:10.0397 (UTC) FILETIME=[6591FCD0:01C6C846] DKIM-Signature: a=rsa-sha1; q=dns; l=2166; t=1156510811; x=1157374811; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20GRUU=20and=20Mid-Dialog=20Requests |To:Xavier=20Marjou=20; X=v=3Dcisco.com=3B=20h=3DBHfEp4ZxQe5icuUoxUyoBEiHrTI=3D; b=mGg/jEq1ksn3g0e6TC0FSAfYkRz5dZtUMs4HvNH/TKUiwhKNUzslUZ6U7WwrzsYU5JR+2qIg b5pFMBAEU29GWV2qprl/QJ/V3YmYfLhwRQUod1Fifpvu6AAyPcd9/7Wg; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Xavier Marjou wrote: > I'm still not 100% convinced that extending the scope of the remote target > (ie: Contact header field) to carry a gruu URI is necessary. > > What about the following alternative mechanism: > > - UA X obtains a GRUU AOR (eg: sip:ua-x;gruu=xyz) either by a response to a > REGISTER request or by an external means. > - UA X must register his GRUU AOR before using it (as it recognize a gruu > aor, the registrar only accepts one address-of-contact, so that forking > towards multiple contacts is not possible) So you are defining the term "GRUU AOR" to mean an AOR that only accepts on registered contact. > - UA X can then use its GRUU AOR in its From header when sending an > "initial" request, or substitute his AOR with its GRUU AOR in the To header > when receiving an "initial" request. That doesn't solve the use cases that GRUU was devised for. The interesting cases are when UA X has registered at an AOR (lets call it AOR-X) that has multiple registered contacts. When UA X answers a dialog establishing request to AOR-X, it needs to put something in the Contact address - something that will route back to it. I suppose, following your proposal, when it receives such a request it could but its gruu into the Contact of the response. But in that case we have all the same issues as the current proposal. > In this case, mid-dialog requests are not impacted. Moreover the anonymous > property of the GRUU AOR may be left out of the GRUU spec, as it comes back > to the general usage in From and To headers. I think I must be missing something key in what you are proposing. It seems like you are simply suggesting that all problems go away if we never allow more than one contact to be registered with an AOR. Paul > Xavier > > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 25 11:58:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGe0s-0006MA-2m; Fri, 25 Aug 2006 11:54:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGe0q-0006M5-7z for sip@ietf.org; Fri, 25 Aug 2006 11:54:28 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGe0l-00015i-LU for sip@ietf.org; Fri, 25 Aug 2006 11:54:28 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Aug 2006 11:54:22 -0400 X-IronPort-AV: i="4.08,169,1154923200"; d="scan'208"; a="98766476:sNHT39903524" 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.20060308/8.12.11) with ESMTP id k7PFsLPL002773; Fri, 25 Aug 2006 11:54:21 -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.12.10/8.12.6) with ESMTP id k7PFsLuI029032; Fri, 25 Aug 2006 11:54:21 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 11:54:21 -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 Subject: RE: [Sip] GRUU and Mid-Dialog Requests Date: Fri, 25 Aug 2006 11:54:20 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301DDA2D5@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Mid-Dialog Requests Thread-Index: AcbIJnlniV89wmtkQUma3B7GoFifOQAN/4GQ From: "Michael Hammer \(mhammer\)" To: "Xavier Marjou" , X-OriginalArrivalTime: 25 Aug 2006 15:54:21.0724 (UTC) FILETIME=[BB0BEDC0:01C6C85E] DKIM-Signature: a=rsa-sha1; q=dns; l=1844; t=1156521261; x=1157385261; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20GRUU=20and=20Mid-Dialog=20Requests |To:=22Xavier=20Marjou=22=20,=20; X=v=3Dcisco.com=3B=20h=3DQbL1BwGX6C4IrpY6rxRMDF3cuUU=3D; b=p57BNLwAojmHJFmYBjbI2GLOk+5XHGlto4G/nWS04es1LVeOzjwl/qbNVRAZVjvrTD3ee8GS OFfooEq89CQNnETWHlwGIqrYymxZuuwmju75eqMZGVNLJN789WdxxHcS; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Is it just me or does something sound fundamentally wrong to call a GRUU an AOR? I thought it was that Contacts are registered to AoRs, and GRUU was just one type of Contact address, where an AoR can map to multiple Contacts, zero or more of which may be GRUUs. Mike > -----Original Message----- > From: Xavier Marjou [mailto:xavier.marjou@orange-ft.com]=20 > Sent: Friday, August 25, 2006 5:07 AM > To: sip@ietf.org > Subject: Re: [Sip] GRUU and Mid-Dialog Requests >=20 > I'm still not 100% convinced that extending the scope of the=20 > remote target > (ie: Contact header field) to carry a gruu URI is necessary.=20 >=20 > What about the following alternative mechanism:=20 >=20 > - UA X obtains a GRUU AOR (eg: sip:ua-x;gruu=3Dxyz) either by a=20 > response to a REGISTER request or by an external means. >=20 > - UA X must register his GRUU AOR before using it (as it=20 > recognize a gruu aor, the registrar only accepts one=20 > address-of-contact, so that forking towards multiple contacts=20 > is not possible) >=20 > - UA X can then use its GRUU AOR in its From header when=20 > sending an "initial" request, or substitute his AOR with its=20 > GRUU AOR in the To header when receiving an "initial" request.=20 >=20 > In this case, mid-dialog requests are not impacted. Moreover=20 > the anonymous property of the GRUU AOR may be left out of the=20 > GRUU spec, as it comes back to the general usage in From and=20 > To headers. >=20 > Xavier >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 13:24:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfNX-0005VM-Ob; Fri, 25 Aug 2006 13:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfNW-0005VG-2n for sip@ietf.org; Fri, 25 Aug 2006 13:21:58 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGfNU-0003a1-Q5 for sip@ietf.org; Fri, 25 Aug 2006 13:21:58 -0400 Received: from [172.20.1.4] (host86-138-1-81.range86-138.btcentralplus.com [86.138.1.81]) by blaster.systems.pipex.net (Postfix) with ESMTP id 5B3CDE000328; Fri, 25 Aug 2006 18:21:44 +0100 (BST) Message-ID: <44EF31A9.107@pjsip.org> Date: Fri, 25 Aug 2006 18:21:45 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] Comments for connect-reuse-06 References: <44ECD134.50603@pjsip.org> <44EDD2AF.90709@lucent.com> <44EDF2A3.4010209@pjsip.org> <44EDF74B.6070706@lucent.com> <44EE24FB.1070402@pjsip.org> <44EF0B2A.5040903@lucent.com> In-Reply-To: <44EF0B2A.5040903@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > NEW: > Once an alias has been established, clients must be prepared > for the case that the connection no longer exists when they > are ready to send a subsequent request over it. In such a case, > a new connection MUST be opened to the resolved address and the > alias table updated accordingly. Looks good. > I actually like the "Once an alias has been established" phrase. > It provides some context that goes a bit beyond the paragraph > that preceeds it. I think I don't quite like it. Unless I misunderstood something, I don't think client has any indication that "an alias has been established". So because of this, client can never say that; it can only say that a connection has been established. -benny _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 13:53:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfpe-0004TX-Ox; Fri, 25 Aug 2006 13:51:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfpe-0004Pi-1E for sip@ietf.org; Fri, 25 Aug 2006 13:51:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGeFm-0002iy-6w for sip@ietf.org; Fri, 25 Aug 2006 12:09:54 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGe5d-0008Oc-SV for sip@ietf.org; Fri, 25 Aug 2006 11:59:29 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Aug 2006 11:59:26 -0400 X-IronPort-AV: i="4.08,169,1154923200"; d="scan'208"; a="98768547:sNHT33235044" 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.20060308/8.12.11) with ESMTP id k7PFxPg2007480; Fri, 25 Aug 2006 11:59:25 -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.12.10/8.12.6) with ESMTP id k7PFxPuI000527; Fri, 25 Aug 2006 11:59:25 -0400 (EDT) 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, 25 Aug 2006 11:59:25 -0400 Received: from [10.86.240.205] ([10.86.240.205]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 11:59:25 -0400 Message-ID: <44EF1E5C.8070507@cisco.com> Date: Fri, 25 Aug 2006 11:59:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Xavier Marjou Subject: Re: [Sip] GRUU and Mid-Dialog Requests References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 15:59:25.0180 (UTC) FILETIME=[6FEBA3C0:01C6C85F] DKIM-Signature: a=rsa-sha1; q=dns; l=3161; t=1156521565; x=1157385565; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20GRUU=20and=20Mid-Dialog=20Requests |To:Xavier=20Marjou=20; X=v=3Dcisco.com=3B=20h=3DBHfEp4ZxQe5icuUoxUyoBEiHrTI=3D; b=FHM1IE0xiqWt5K3DGw+rnpD/9sbr7bGZjQdimKvrSXPUsRYJMJSIW4R9w9/m97hkPi9a7ckN g40wMkRE3Lb3YUomxP+hhKeRHIRB3l0Dm8Id2UIaAU86W2S1EHAuFrfT; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Xavier Marjou wrote: >> That doesn't solve the use cases that GRUU was devised for. > >> The interesting cases are when UA X has registered at an AOR >> (lets call it AOR-X) that has multiple registered contacts. >> When UA X answers a dialog establishing request to AOR-X, >> it needs to put something in the Contact address - something >> that will route back to it. > >> I suppose, following your proposal, when it receives such a request >> it could but its gruu into the Contact of the response. But in that >> case we have all the same issues as the current proposal. > > Let's say UA X has a regular AOR (AOR-X), and 2 GRUU AOR (AOR-X;gruu=111 > and AOR-X;gruu=222). The above is a little confusing, because I had assumed "UA X" referred to a user agent, but the way you are using it it seems to refer to a user with two user agents (devices). But now that I see how you are using the terms I can manage for now. > When registering from device1, he both both AOR-X and AOR-X;gruu=111 > When registering from device2, he both both AOR-X and AOR-X;gruu=222 > > When UA X answers a call on device1, it updates the addr in the "To" header > with its GRUU AOR (AOR-X;gruu=111), but it does not modify the remote- > target (Contact). I'm not sure what you are suggesting here. Updating the To header is currently not allowed. There have been some suggestions to permit it to be changed in a subsequent UPDATE request. Is that what you have in mind? It would be helpful if you would send an example, containing the messages and headers that you propose using. > Then the remote peer can use this GRUU-AOR to send a > SUBSCRIBE for example. Of course, I know this breaks what has been > envisioned for so far that is to advertise the GRUU in the remote-target. Ignoring the details, this is similar to a proposal long ago to carry the gruu in a new header, rather than in the Contact header. That was abandoned because it would require changes in previously conforming implementations to work with UAs conforming to gruu. Maybe what you have in mind will have a new twist. If you want, send out something with more detail. BUT, the gruu proposal has been baking for a long time, so this is kind of late to consider a major change. Paul >> So you are defining the term "GRUU AOR" to mean an AOR >> that only accepts on registered contact. > > Yes, the idea would be to register the regular AOR from all devices (as > usual many addr of contact are allowed) and to also regiter one derived > AOR-GRUU per device (for each AOR-GRUU, only one addr of contact is > allowed). > > >> I think I must be missing something key in what you are proposing. >> It seems like you are simply suggesting that all problems go away >> if we never allow more than one contact to be registered with an AOR. > > I would certainly not pretend that "all the problems go away" for this > complex topic ;-) I know I may not be aware of the whole story nor of all > the possible impacts. Just consider it as an alternative I suggest to > investigate. > > > > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 15:18:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGh9w-0001jr-UO; Fri, 25 Aug 2006 15:16:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGh9v-0001ih-61 for sip@ietf.org; Fri, 25 Aug 2006 15:16:03 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGh9t-0007my-Ct for sip@ietf.org; Fri, 25 Aug 2006 15:16:03 -0400 Received: from [64.101.149.121] (gmatulka-w2k01.cisco.com [64.101.149.121]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7PJIKdg001085 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 25 Aug 2006 14:18:22 -0500 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301DDA2D5@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E301DDA2D5@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] GRUU and Mid-Dialog Requests Date: Fri, 25 Aug 2006 14:15:53 -0500 To: Michael Hammer ((mhammer)) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, Xavier Marjou X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 25, 2006, at 10:54 AM, Michael Hammer ((mhammer)) wrote: > Is it just me or does something sound fundamentally wrong to call a > GRUU > an AOR? > > I thought it was that Contacts are registered to AoRs, and GRUU was > just > one type of Contact address, where an AoR can map to multiple > Contacts, > zero or more of which may be GRUUs. > That's consistent with my view of GRUU. I see a GRUU as an alias for a Contact URI that can be used in place of a Contact URI. As such, a GRUU is a URI, but not an AOR. It's important to understand the the GRUU, while we use the word "Global", isn't necessarily global. All we can be sure of is that the GRUU is valid in the "external" context of the node assigning the GRUU. This is important, because in many scenarios, that node also has an "internal" context, and the Contact URI used for registration is probably valid only in that internal context. Of course, if the external context happens to be "the Internet", then we're pretty close to globally routable, but the GRUU mechanism is still useful even in cases like enterprises with internal NATs. But GRUU sounds much cooler than ERUU to a native English speaker (or to a player of adventure games who has been eaten by a grue too many times). -- Dean _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 16:17:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGi4A-00065n-Oc; Fri, 25 Aug 2006 16:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGi49-00065R-Ag; Fri, 25 Aug 2006 16:14:09 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGi43-0000l7-4T; Fri, 25 Aug 2006 16:14:09 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Fri, 25 Aug 2006 16:09:01 -0400 id 015880C4.44EF58DE.00003E05 Message-ID: <44EF58D8.3030100@hxr.us> Date: Fri, 25 Aug 2006 16:08:56 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: IETF SIP List Subject: [Sip] rethinking data: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Having reviewed the archives on the recent location conveyance discussion, I see that I was the only one to raise an objection to the use of a data: URL in the Location header. My objection was based on the fact that it would add unnecessary complexity. Given some more time to think this through, I believe it adds no more complexity than the alternative... even much less complexity than the alternatives especially if there is no desire to specify its use with XML D-Sig. Of course, the use of this mechanism MUST be restricted specifically to emergency scenarios, and only when location is not present in the body. -andy _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 18:05:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGjkY-0006FJ-VB; Fri, 25 Aug 2006 18:02:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGjkW-0006CO-UT; Fri, 25 Aug 2006 18:02:00 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGjkT-0001bp-IV; Fri, 25 Aug 2006 18:02:00 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 25 Aug 2006 15:01:57 -0700 X-IronPort-AV: i="4.08,170,1154934000"; d="scan'208"; a="1850408389:sNHT31980240" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PM1rlV005113; Fri, 25 Aug 2006 15:01:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7PM1kwF020009; Fri, 25 Aug 2006 15:01:53 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 15:01:53 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.154.14]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 15:01:52 -0700 Message-Id: <4.3.2.7.2.20060825170030.03450eb8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Aug 2006 17:01:50 -0500 To: Andrew Newton , GEOPRIV From: "James M. Polk" In-Reply-To: <44EF58D8.3030100@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 25 Aug 2006 22:01:53.0066 (UTC) FILETIME=[12ABB0A0:01C6C892] DKIM-Signature: a=rsa-sha1; q=dns; l=1007; t=1156543313; x=1157407313; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Geopriv]=20rethinking=20data=3A; X=v=3Dcisco.com=3B=20h=3Dfe/iQprSi1A6wwg52A+5Sz1iiVA=3D; b=nPLclbQI0Jx9LueoowIGW82+84yWEestL1QKOQD439WsFqPA9E65DoHAbiCYr8ITFR2vVARU NJtU9uXcGAkXb1sTfmfP2Zok0Np45cfYa09B5eSmDRYWowWUl0vdkgBV; Authentication-Results: sj-dkim-8.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List Subject: [Sip] Re: [Geopriv] rethinking data: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 04:08 PM 8/25/2006 -0400, Andrew Newton wrote: >Having reviewed the archives Andy Which archives did you review? There were several voices opposed to it, but maybe not on the Geopriv list. After all, this is a SIP doc... >on the recent location conveyance discussion, I see that I was the only >one to raise an objection to the use of a data: URL in the Location header. > >My objection was based on the fact that it would add unnecessary >complexity. Given some more time to think this through, I believe it adds >no more complexity than the alternative... even much less complexity than >the alternatives especially if there is no desire to specify its use with >XML D-Sig. Of course, the use of this mechanism MUST be restricted >specifically to emergency scenarios, and only when location is not present >in the body. > >-andy > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 20:25:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGlvh-0007jS-HC; Fri, 25 Aug 2006 20:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGlvf-0007j7-ID; Fri, 25 Aug 2006 20:21:39 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGlvc-0005WV-Au; Fri, 25 Aug 2006 20:21:39 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 25 Aug 2006 20:21:30 -0400 id 01588355.44EF940A.000066D5 In-Reply-To: <4.3.2.7.2.20060825170030.03450eb8@email.cisco.com> References: <4.3.2.7.2.20060825170030.03450eb8@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Fri, 25 Aug 2006 20:21:30 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: GEOPRIV , IETF SIP List Subject: [Sip] Re: [Geopriv] rethinking data: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 25, 2006, at 6:01 PM, James M. Polk wrote: > At 04:08 PM 8/25/2006 -0400, Andrew Newton wrote: >> Having reviewed the archives > > Andy > > Which archives did you review? > > There were several voices opposed to it, but maybe not on the > Geopriv list. After all, this is a SIP doc... I'm well aware of that fact, James. However, there was actually very little significant discussion on it besides the exchange between Henning and myself (there was a post on the SIP list that never made it to GEOPRIV that was in favor). Keep in mind, this was mixed into a long and winding thread. So, here we have another thread. And it would be easy for those opposed (or for) to stand up and be counted (and offer an explanation, too... after all, we don't vote in the IETF). -andy _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 20:46:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmHO-00022y-IJ; Fri, 25 Aug 2006 20:44:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmHM-00022l-W0 for sip@ietf.org; Fri, 25 Aug 2006 20:44:05 -0400 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGmHK-000820-Gy for sip@ietf.org; Fri, 25 Aug 2006 20:44:04 -0400 Received: (qmail 31725 invoked by uid 0); 26 Aug 2006 00:43:51 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Aug 2006 00:43:51 -0000 Message-ID: <001801c6c8a8$b4ca1000$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Andrew Newton" , "James M. Polk" References: <4.3.2.7.2.20060825170030.03450eb8@email.cisco.com> Subject: Re: [Sip] Re: [Geopriv] rethinking data: Date: Sat, 26 Aug 2006 02:43:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: GEOPRIV , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Andy, A data: URI enables the following use case: location-by-value inserted by a proxy. Especially for emergency cases, location-by-value is good to have: less delay (no additional de-reference) and less ways in which things can fail. Although I'm not particularly keen on the syntax defined for data: URIs, I think the use case and benefits it enables are worthwhile Regards, Jeroen ----- Original Message ----- From: "Andrew Newton" To: "James M. Polk" Cc: "GEOPRIV" ; "IETF SIP List" Sent: Saturday, August 26, 2006 2:21 AM Subject: [Sip] Re: [Geopriv] rethinking data: > > On Aug 25, 2006, at 6:01 PM, James M. Polk wrote: > >> At 04:08 PM 8/25/2006 -0400, Andrew Newton wrote: >>> Having reviewed the archives >> >> Andy >> >> Which archives did you review? >> >> There were several voices opposed to it, but maybe not on the Geopriv >> list. After all, this is a SIP doc... > > I'm well aware of that fact, James. However, there was actually very > little significant discussion on it besides the exchange between Henning > and myself (there was a post on the SIP list that never made it to > GEOPRIV that was in favor). Keep in mind, this was mixed into a long and > winding thread. > > So, here we have another thread. And it would be easy for those opposed > (or for) to stand up and be counted (and offer an explanation, too... > after all, we don't vote in the IETF). > > -andy > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Fri Aug 25 20:52:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmNV-0005RD-2o; Fri, 25 Aug 2006 20:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmNT-0005QB-Iw; Fri, 25 Aug 2006 20:50:23 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGmNS-0000HQ-7h; Fri, 25 Aug 2006 20:50:23 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 19:50:19 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 25 Aug 2006 19:50:19 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 19:50:18 -0500 Message-ID: From: "Dawson, Martin" To: "Andrew Newton" , "James M. Polk" Date: Fri, 25 Aug 2006 19:50:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Aug 2006 00:50:18.0737 (UTC) FILETIME=[9A1EB610:01C6C8A9] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] rethinking data: Thread-Index: AcbIpciO15HDjdU3STWDNgQgWbxdUwAAZr4w X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: GEOPRIV , IETF SIP List Subject: [Sip] RE: [Geopriv] rethinking data: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Tsk. Once more, then, into the breach... I vote in FAVOR of location reference. Protocols definition is an engineering activity - protocol features are provided for practical purposes and should not be added or excluded as a projection of ideologies. Practical benefits of location reference: * The literal location does not need to be transmitted in band. Where the eventual recipient and de-referencer is the only party the "owner" of location cares to provide disclosure to, then the reference mechanism achieves this. Particularly useful where the owner is not in a peer signaling relationship with the de-referencer. E.g. a VoIP emergency caller and a VPC. * The location reference form is immutable and generic (i.e. a URI - and my view that a generic URI is perfectly adequate has also been expressed). So, no matter what eventual modifications, extensions, or additions are made to the manner in which the PIDF-LO is formed, the conveyance path need not be concerned about backward incompatibility. Adaption is limited to the actual end-user of the location information. * Where the location owner is not in a peer signaling relationship with the location user (e.g. a VoIP emergency caller and a VPC), the location reference can be permitted to be valid for a period of time allowing, for example, the retrieval of location updates during the period of that session. * As a counter-response - no the location reference is not less secure. Losing privacy of location information means losing the information at the device or in transit. Loss of a literal location object means the location is lost in one step. Loss of a reference still requires the unauthorized party to successfully breach the authentication and authorization barrier at the referenced server. Location by reference provides superior privacy. * The DSIG solution for DHCP/LLDP-MED contributed by Rosen et al recently does not address the temporal component. Brian should state the signature also needs to provide an expiry-time component. Else the signed LO can be replayed at any time in the future from anywhere by the original recipient. Expiry time semantics are somewhat awkward. Since de-referencing is an instantaneous process, the location server can apply temporal rules directly without the need to encode them in the location object itself. I think that's a more than compelling list of benefits of using location reference. Arguments suggesting it allows network operators to charge for location are not relevant - nor appropriate to the engineering process. The market will decide that - and clearly the option of providing literal location is not obviated by the presence of the option to use location by reference. Cheers, Martin > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Saturday, 26 August 2006 10:22 AM > To: James M. Polk > Cc: GEOPRIV; IETF SIP List > Subject: Re: [Geopriv] rethinking data: >=20 >=20 > On Aug 25, 2006, at 6:01 PM, James M. Polk wrote: >=20 > > At 04:08 PM 8/25/2006 -0400, Andrew Newton wrote: > >> Having reviewed the archives > > > > Andy > > > > Which archives did you review? > > > > There were several voices opposed to it, but maybe not on the > > Geopriv list. After all, this is a SIP doc... >=20 > I'm well aware of that fact, James. However, there was actually very > little significant discussion on it besides the exchange between > Henning and myself (there was a post on the SIP list that never made > it to GEOPRIV that was in favor). Keep in mind, this was mixed into > a long and winding thread. >=20 > So, here we have another thread. And it would be easy for those > opposed (or for) to stand up and be counted (and offer an > explanation, too... after all, we don't vote in the IETF). >=20 > -andy >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 21:04:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmYz-00035P-Ur; Fri, 25 Aug 2006 21:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmYy-000353-HX; Fri, 25 Aug 2006 21:02:16 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGmYy-00026Y-0m; Fri, 25 Aug 2006 21:02:16 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 20:02:15 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 25 Aug 2006 20:02:15 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 20:02:14 -0500 Message-ID: From: "Dawson, Martin" To: "Drage, Keith \(Keith\)" , "Andrew Newton" , "Winterbottom, James" Date: Fri, 25 Aug 2006 20:02:11 -0500 Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have anHTTPdereferencemechanism defined MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Aug 2006 01:02:14.0576 (UTC) FILETIME=[44CB1300:01C6C8AB] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <5D1A7985295922448D5550C94DE2918030B2E8@DEEXC1U01.de.lucent.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Does Location-Conveyance have anHTTPdereferencemechanism defined Thread-Index: Aca1B+ZeLLsjYFmHQQ2U8yRlbuTwXgAIJqCAAtvtv1AAHNzGYAGdm0LwAEntMAA= X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: IETF SIP List , "Rosen, Brian" , GEOPRIV X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I certainly don't think a normative reference is necessary. It could normatively reference the existing Geopriv document that says what the requirements are for a using protocol. As James P's reaction indicated, maintaining such a document would be a pain in the fundament. And, so, if it's not something that is considered reasonable to do (given the rules for what constitutes a valid using protocol are documented at the meta-level) as a geopriv document, why on earth would a SIP conveyance document take it upon itself to represent a definitive list of valid using protocols? Just to make this clear - there are several versions of using protocols that support a reference mechanism under development and proposal. And, hey, some are not even in the IETF domain. They may well use a transport other than SIP, but can still get acceptance and ratification as meeting the requirements of a using protocol. The last thing we need is to then have the protocol police saying "well sorry, you can't send one of those references, the *SIP* standard doesn't recognize it. You'll have to go through a couple of years of more tedious debate to get it added to the conveyance spec." That's not actually even in the interests of SIP. Cheers, Martin > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Friday, 25 August 2006 12:33 AM > To: Dawson, Martin; Andrew Newton; Winterbottom, James > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have > anHTTPdereferencemechanism defined >=20 > So in order to complete, we therefore need a new GEOPRIV draft that > defines the list of dereferencing protocols, and which location > conveyance will normatively reference? >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: 16 August 2006 09:25 > > To: Drage, Keith (Keith); Andrew Newton; Winterbottom, James > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance > > have anHTTPdereferencemechanism defined > > > > Hi Keith, > > > > 1. I disagree that a HTTP URI indicates anything about the > > using protocol other than the transport it uses. HTTP is the > > transport. A SIP URI could equally indicate a SIP transport > > but with a set of protocol semantics that do not honor the > > geopriv requirements. > > > > 2. No - as above - the reference URI does not convey > > information about the nature of the user protocol that the > > referenced server is going to support. Also, even if the URI > > did indicate the nature of the using protocol, it is not > > appropriate to have to continually update a SIP document > > every time a new geopriv compliant user protocol is invented. > > The SIP conveyance cannot assure anything about the integrity > > of the using protocol supported by the referenced server and > > it should not imply that it can. Services that are provided > > for the purpose of location object conveyance will need to be > > assessed themselves as to whether they meet the geopriv constraints. > > > > 3. I think geopriv could maintain a document of *actual using > > protocols* that are considered to meet the geopriv > > constraints. Noting that listing the actual protocols also > > conveys more than the type of URI that could be used to > > reference a server supporting those protocols. At least, > > then, there would be a single place to maintain this > > information and the SIP specification can simply state that > > the URI, whatever its form, must be a reference to a server > > which supports a using protocol that honors geopriv > > constraints - as could every one of the other protocols that > > I would certainly hope are going to be able to convey a > > location reference > > - and without having to be updated every time a new using > > protocol is defined. > > > > Cheers, > > Martin > > > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: Wednesday, 16 August 2006 4:32 AM > > > To: Dawson, Martin; Andrew Newton; Winterbottom, James > > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have > > > anHTTPdereferencemechanism defined > > > > > > I must admit I am still having trouble working out what > > your position, > > > and that of Henning and James W. is. > > > > > > 1) The dereferencing protocol is a using protocol according to > the > > > GEOPRIV RFCs. I assume that GEOPRIV is therefore going to > > require that > > > such a using protocol meets their requirements. HTTP in its current > > form > > > does not meet those requirements. Is there anything here > > you disagree > > > with? > > > > > > 2) So then we get to the step of should the URI conveyance police > > > the using protocol that can be used, which is essentially what Brian > > is > > > proposing. I certainly understand that it should be policed > > somewhere, > > > and if it is not policed by the syntax of the protocol, it > > either has > > to > > > be policed by the dereferencer, or by the location provider itself. > > > Where do you stand on this? To me it seems automatic to police it by > > the > > > types of URI that are allowed to be used, and therefore I need to > > > understand how you see this. > > > > > > 3) If you agree that we police by the types of URI to be used, is > > > the problem here then that GEOPRIV rather than SIP should write the > > > document that makes these constraints? > > > > > > Regards > > > > > > Keith > > > > > > > > > > > > > -----Original Message----- > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > Sent: 01 August 2006 06:14 > > > > To: Andrew Newton; Winterbottom, James > > > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > > > Subject: RE: [Sip] RE: [Geopriv] Does Location-Conveyance have > > > > anHTTPdereferencemechanism defined > > > > > > > > I'm OK as long as the ABNF includes the AbsoluteURI > > option and the > > > > text does not say anything specifically about excluding > > HTTP (or any > > > > other form of URI). > > > > > > > > I've attempted to point out previously that the URI > > doesn't actually > > > > convey anything about whether the geopriv rules are going to be > > > > respected or not. It's actually a geopriv rule that those > > rules be > > > > respected so it's superfluous, and out of scope, to also > > require the > > > > statement in a SIP conveyance document. > > > > > > > > AbsoluteURI as a generic form, encompasses sip etc. > > anyway, so it's > > > > also superfluous to include those in the ABNF. > > > > However, it's also a harmless waste of space. If Brian is keen to > > > > include them for some reason, and as long as neither the text nor > > > > the ABNF bias the specification toward those forms in any > > way, then > > > > there are certainly better things to lose sleep over. > > > > > > > > Cheers, > > > > Martin > > > > > > > > > -----Original Message----- > > > > > From: Andrew Newton [mailto:andy@hxr.us] > > > > > Sent: Tuesday, 1 August 2006 11:15 AM > > > > > To: Winterbottom, James > > > > > Cc: IETF SIP List; Rosen, Brian; GEOPRIV > > > > > Subject: Re: [Sip] RE: [Geopriv] Does > > Location-Conveyance have an > > > > > HTTPdereferencemechanism defined > > > > > > > > > > > > > > > On Jul 31, 2006, at 9:11 PM, Winterbottom, James wrote: > > > > > > > > > > > Hi Andy, > > > > > > > > > > > > That is all I have asked for, do not constrain the ABNF. > > > > If "how I > > > > > > use HTTP as a reference" goes in a different document > > > > that is fine > > > > > > providing the ABNF is not constrained in the conveyance > > > > > > specification. This is not how I read Brian's statement below: > > > > > > > > > > > > "This is NOT the discussion of what the ABNF of the > > > > location header > > > > > > looks like (although it would NOT have http/https in it > > > > for sure if > > > > > > we > > > > agree > > > > > > that an HTTP dereference protocol is a separate draft)." > > > > > > > > > > > > Which to me clearly says the ABNF will be restrict to > > > > exclude HTTP/ > > > > > > HTTPS if there is agreement that the conveyance draft > > > > doesn't have > > > > > > specific text on how to deference an HTTP reference. > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > Please keep in mind that this does not stop the draft from > > > > using MUST/ > > > > > SHOULD language from stipulating "the URI MUST be a GEOPRIV > > > > standards > > > > > track using protocol." > > > > > > > > > > -andy > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > -------------------------------------------------------------- > > > > ---------------------------------- > > > > This message is for the designated recipient only and may contain > > > > privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized > > use of this > > > > email is prohibited. > > > > -------------------------------------------------------------- > > > > ---------------------------------- > > > > [mf2] > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 21:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmee-0006eY-7v; Fri, 25 Aug 2006 21:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGmec-0006eQ-Sh; Fri, 25 Aug 2006 21:08:06 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGmea-0002HL-Ij; Fri, 25 Aug 2006 21:08:06 -0400 Received: from [192.168.0.41] (pool-138-89-38-92.mad.east.verizon.net [138.89.38.92]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k7Q14fkv023360 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 25 Aug 2006 21:04:42 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] rethinking data: Date: Fri, 25 Aug 2006 21:04:30 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: GEOPRIV , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I thought we had long ago agreed that both by-value and by-reference have their benefits and drawbacks. Why are we re-opening this debate? Are you suggesting that we remove all by-value usage of LOs? Do you think you can get WG consensus on this? I won't rebut the statements below point-by-point. Suffice it to say that the problem is that the arguments in favor of reference shape- shift, as they actually encompass multiple forms (with retriever authorization, possession-only, among others), and conveniently claim the benefits of the union of them, while admitting only to the drawbacks of the intersection. This is not helpful for an enlightening debate. However, given that we've gone through this now at least a dozen times, I don't see the point of rehashing the same debate again. Maybe the chair(s) can ask, if this is indeed necessary, for consensus on the first line of this message and declare such debates as not helpful? Henning On Aug 25, 2006, at 8:50 PM, Dawson, Martin wrote: > Tsk. Once more, then, into the breach... > > I vote in FAVOR of location reference. Protocols definition is an > engineering activity - protocol features are provided for practical > purposes and should not be added or excluded as a projection of > ideologies. > > Practical benefits of location reference: > * The literal location does not need to be transmitted in band. Where > the eventual recipient and de-referencer is the only party the "owner" > of location cares to provide disclosure to, then the reference > mechanism > achieves this. Particularly useful where the owner is not in a peer > signaling relationship with the de-referencer. E.g. a VoIP emergency > caller and a VPC. > > * The location reference form is immutable and generic (i.e. a URI > - and > my view that a generic URI is perfectly adequate has also been > expressed). So, no matter what eventual modifications, extensions, or > additions are made to the manner in which the PIDF-LO is formed, the > conveyance path need not be concerned about backward incompatibility. > Adaption is limited to the actual end-user of the location > information. > > * Where the location owner is not in a peer signaling relationship > with > the location user (e.g. a VoIP emergency caller and a VPC), the > location > reference can be permitted to be valid for a period of time allowing, > for example, the retrieval of location updates during the period of > that > session. > > * As a counter-response - no the location reference is not less > secure. > Losing privacy of location information means losing the information at > the device or in transit. Loss of a literal location object means the > location is lost in one step. Loss of a reference still requires the > unauthorized party to successfully breach the authentication and > authorization barrier at the referenced server. Location by reference > provides superior privacy. > > * The DSIG solution for DHCP/LLDP-MED contributed by Rosen et al > recently does not address the temporal component. Brian should > state the > signature also needs to provide an expiry-time component. Else the > signed LO can be replayed at any time in the future from anywhere > by the > original recipient. Expiry time semantics are somewhat awkward. Since > de-referencing is an instantaneous process, the location server can > apply temporal rules directly without the need to encode them in the > location object itself. > > I think that's a more than compelling list of benefits of using > location > reference. Arguments suggesting it allows network operators to charge > for location are not relevant - nor appropriate to the engineering > process. The market will decide that - and clearly the option of > providing literal location is not obviated by the presence of the > option > to use location by reference. > > Cheers, > Martin > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 22:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGnjx-0001Iy-GA; Fri, 25 Aug 2006 22:17:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGnjw-0001Ic-4p; Fri, 25 Aug 2006 22:17:40 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGnjt-00035c-Pq; Fri, 25 Aug 2006 22:17:40 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 21:17:37 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 25 Aug 2006 21:17:36 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 21:17:35 -0500 Message-ID: From: "Dawson, Martin" To: "Henning Schulzrinne" Date: Fri, 25 Aug 2006 21:17:34 -0500 Subject: RE: [Sip] RE: [Geopriv] rethinking data: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Aug 2006 02:17:35.0954 (UTC) FILETIME=[CBBE9B20:01C6C8B5] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] rethinking data: Thread-Index: AcbIrBZdDTnDsEfZRm+aViIYadGhUQACTyBQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: GEOPRIV , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Beats me Henning (and not that I understand the shape-shifting allusion either). Andy just said "So, here we have another thread. And it would be easy for those opposed (or for) to stand up and be counted (and offer an explanation, too... after all, we don't vote in the IETF)." So I responded in the spirit of the request as someone who is for reference conveyance. Don't know where you'd get the idea I wanted by-value removed. That'd be silly. Cheers, Martin > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, 26 August 2006 11:05 AM > To: Dawson, Martin > Cc: GEOPRIV; IETF SIP List > Subject: Re: [Sip] RE: [Geopriv] rethinking data: >=20 > I thought we had long ago agreed that both by-value and by-reference > have their benefits and drawbacks. Why are we re-opening this debate? > Are you suggesting that we remove all by-value usage of LOs? Do you > think you can get WG consensus on this? >=20 > I won't rebut the statements below point-by-point. Suffice it to say > that the problem is that the arguments in favor of reference shape- > shift, as they actually encompass multiple forms (with retriever > authorization, possession-only, among others), and conveniently claim > the benefits of the union of them, while admitting only to the > drawbacks of the intersection. This is not helpful for an > enlightening debate. >=20 > However, given that we've gone through this now at least a dozen > times, I don't see the point of rehashing the same debate again. > Maybe the chair(s) can ask, if this is indeed necessary, for > consensus on the first line of this message and declare such debates > as not helpful? >=20 > Henning >=20 > On Aug 25, 2006, at 8:50 PM, Dawson, Martin wrote: >=20 > > Tsk. Once more, then, into the breach... > > > > I vote in FAVOR of location reference. Protocols definition is an > > engineering activity - protocol features are provided for practical > > purposes and should not be added or excluded as a projection of > > ideologies. > > > > Practical benefits of location reference: > > * The literal location does not need to be transmitted in band. Where > > the eventual recipient and de-referencer is the only party the "owner" > > of location cares to provide disclosure to, then the reference > > mechanism > > achieves this. Particularly useful where the owner is not in a peer > > signaling relationship with the de-referencer. E.g. a VoIP emergency > > caller and a VPC. > > > > * The location reference form is immutable and generic (i.e. a URI > > - and > > my view that a generic URI is perfectly adequate has also been > > expressed). So, no matter what eventual modifications, extensions, or > > additions are made to the manner in which the PIDF-LO is formed, the > > conveyance path need not be concerned about backward incompatibility. > > Adaption is limited to the actual end-user of the location > > information. > > > > * Where the location owner is not in a peer signaling relationship > > with > > the location user (e.g. a VoIP emergency caller and a VPC), the > > location > > reference can be permitted to be valid for a period of time allowing, > > for example, the retrieval of location updates during the period of > > that > > session. > > > > * As a counter-response - no the location reference is not less > > secure. > > Losing privacy of location information means losing the information at > > the device or in transit. Loss of a literal location object means the > > location is lost in one step. Loss of a reference still requires the > > unauthorized party to successfully breach the authentication and > > authorization barrier at the referenced server. Location by reference > > provides superior privacy. > > > > * The DSIG solution for DHCP/LLDP-MED contributed by Rosen et al > > recently does not address the temporal component. Brian should > > state the > > signature also needs to provide an expiry-time component. Else the > > signed LO can be replayed at any time in the future from anywhere > > by the > > original recipient. Expiry time semantics are somewhat awkward. Since > > de-referencing is an instantaneous process, the location server can > > apply temporal rules directly without the need to encode them in the > > location object itself. > > > > I think that's a more than compelling list of benefits of using > > location > > reference. Arguments suggesting it allows network operators to charge > > for location are not relevant - nor appropriate to the engineering > > process. The market will decide that - and clearly the option of > > providing literal location is not obviated by the presence of the > > option > > to use location by reference. > > > > Cheers, > > Martin > > >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Fri Aug 25 23:17:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGod2-0005JJ-2r; Fri, 25 Aug 2006 23:14:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGod0-0005Iv-Hb; Fri, 25 Aug 2006 23:14:34 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGocz-00040F-B4; Fri, 25 Aug 2006 23:14:34 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 25 Aug 2006 23:14:25 -0400 id 0158814F.44EFBC91.00007CB4 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27145AD8-AB5D-40CD-B53D-D6B22015B714@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Sip] RE: [Geopriv] rethinking data: Date: Fri, 25 Aug 2006 23:14:25 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: GEOPRIV , IETF SIP List , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 25, 2006, at 10:17 PM, Dawson, Martin wrote: > Beats me Henning (and not that I understand the shape-shifting > allusion > either). > > Andy just said > > "So, here we have another thread. And it would be easy for those > opposed (or for) to stand up and be counted (and offer an explanation, > too... after all, we don't vote in the IETF)." > > So I responded in the spirit of the request as someone who is for > reference conveyance. > > Don't know where you'd get the idea I wanted by-value removed. > That'd be > silly. Martin, I have to confess that I read your message in much the same way Henning did. In fact, I was about to reply with "Why do you believe the data: URL is to the exclusion of any other URL type?" Thanks for clearing this up. I was speaking specifically about the usage of the data: URL. -andy _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sat Aug 26 00:51:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGq5a-0004XE-EX; Sat, 26 Aug 2006 00:48:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGq5Y-0004Wm-G7; Sat, 26 Aug 2006 00:48:08 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGpy1-00080r-PJ; Sat, 26 Aug 2006 00:40:22 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 23:40:21 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 25 Aug 2006 23:40:21 -0500 Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 23:40:20 -0500 Message-ID: From: "Dawson, Martin" To: "Andrew Newton" Date: Fri, 25 Aug 2006 23:40:18 -0500 Subject: RE: [Sip] RE: [Geopriv] rethinking data: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Aug 2006 04:40:20.0438 (UTC) FILETIME=[BC932760:01C6C8C9] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <27145AD8-AB5D-40CD-B53D-D6B22015B714@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] rethinking data: Thread-Index: AcbIvb8K/5MxhMA3RUas0rFsD9BcQwAC+pgw X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: GEOPRIV , IETF SIP List , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ah - I see. Well put it all back in the box then. :) Cheers, Martin > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Saturday, 26 August 2006 1:14 PM > To: Dawson, Martin > Cc: Henning Schulzrinne; GEOPRIV; IETF SIP List > Subject: Re: [Sip] RE: [Geopriv] rethinking data: >=20 >=20 > On Aug 25, 2006, at 10:17 PM, Dawson, Martin wrote: >=20 > > Beats me Henning (and not that I understand the shape-shifting > > allusion > > either). > > > > Andy just said > > > > "So, here we have another thread. And it would be easy for those > > opposed (or for) to stand up and be counted (and offer an explanation, > > too... after all, we don't vote in the IETF)." > > > > So I responded in the spirit of the request as someone who is for > > reference conveyance. > > > > Don't know where you'd get the idea I wanted by-value removed. > > That'd be > > silly. >=20 > Martin, >=20 > I have to confess that I read your message in much the same way > Henning did. In fact, I was about to reply with "Why do you believe > the data: URL is to the exclusion of any other URL type?" Thanks for > clearing this up. >=20 > I was speaking specifically about the usage of the data: URL. >=20 > -andy ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Sun Aug 27 20:31:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHUw2-0001dS-4A; Sun, 27 Aug 2006 20:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHUvz-0001dG-CP for sip@ietf.org; Sun, 27 Aug 2006 20:24:59 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHUvv-0005O8-VV for sip@ietf.org; Sun, 27 Aug 2006 20:24:59 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.6/IER-o) with ESMTP id k7S0OVTo001695 for ; Sun, 27 Aug 2006 19:24:36 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 27 Aug 2006 19:24:49 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Aug 2006 02:24:48 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Continuation of WGLC on draft-ietf-sip-gruu-10 Date: Mon, 28 Aug 2006 02:24:48 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918030B79D@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Continuation of WGLC on draft-ietf-sip-gruu-10 Thread-Index: Aca4t6jzb0cIdg3jQp2xn/3iF5Fd1gRcnWrA From: "Drage, Keith \(Keith\)" To: "Drage, Keith \(Keith\)" , "IETF SIP List" X-OriginalArrivalTime: 28 Aug 2006 00:24:48.0977 (UTC) FILETIME=[5F235C10:01C6CA38] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I am having to reschedule the call on the 4th as a critical participant is no longer available. I will still be compiling the comments received over the next week or so. The conference call on the 4th is therefore cancelled. Please keep an eye open for the rescheduled dates. Regards Keith > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: 05 August 2006 21:31 > To: IETF SIP List > Subject: [Sip] Continuation of WGLC on draft-ietf-sip-gruu-10 >=20 > Working Group Last Call > ----------------------- >=20 > Jonathan has just published > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-10.txt > which should take into account all the major comments that=20 > have been so far received on this document. >=20 > Having initiated WGLC on this document on 13th January 2004,=20 > and revised that WGLC on 5th July 2004 and 26th October 2005=20 > we would really like to reach a final conclusion of this WGLC.=20 >=20 > Therefore please review the document and submit your WGLC=20 > comments within two weeks, ie. By the 21st August 2006. >=20 > Process > ------- >=20 > In addition to an open invitation for review by all members=20 > of the working group, we will be soliciting full review by a=20 > number of experts who we believe will provide a good and=20 > complete understanding of the issues and problems, if any,=20 > with the document. If you consider you should be part of this=20 > list this please contact the WG chairs. >=20 > The WG chairs will compile all submitted comments into a=20 > single review document which will be discussed on the=20 > conference call below. Please therefore submit your comments=20 > (to the SIP WG list and the WG chairs) with information under=20 > the following headings for each comment: >=20 > - location in document > - nature of comment (editorial, minor technical, critical error, > absolute show stopper - use your judgement on this) > - comment > - proposed fix >=20 > We intend to have a conference call for reviewers to conclude=20 > on the quality of the document on Monday 4th September at: >=20 > 8:00 am Pacific Time > 10:00 am Central US Time > 11:00 am Eastern US Time > 4:00 pm UK > 5:00 pm Central European Summer Time >=20 > Bridge details as follows: >=20 > Access Phone Number: 8007718734 > International Access Phone Number: +1 6477233953 7-Digit=20 > Access Code: 5776249=20 >=20 > While this call is open to all WG members, we would expect=20 > only people who have reviewed the document on this conference=20 > call. For details of the process please see previous=20 > communication. Note that the above does include those=20 > reviewers who reviewed the document and had no comments - if=20 > you are in this class, please report it. >=20 > Regards >=20 > Keith >=20 > Keith Drage > drage@lucent.com > tel: +44 1793 776249 >=20 > _______________________________________________ > Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Mon Aug 28 03:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHbpB-0000Z1-4B; Mon, 28 Aug 2006 03:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHbp9-0000RK-PF for sip@ietf.org; Mon, 28 Aug 2006 03:46:23 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHbp7-0006Ks-9d for sip@ietf.org; Mon, 28 Aug 2006 03:46:23 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7S7kFpD013359; Mon, 28 Aug 2006 10:46:18 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 10:46:18 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 10:46:17 +0300 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 Subject: RE: [Sip] updated GRUU spec - routing via home domain Date: Mon, 28 Aug 2006 10:46:16 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02A726DE@esebe103.NOE.Nokia.com> In-Reply-To: <44CE6FFC.4010000@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] updated GRUU spec - routing via home domain thread-index: Aca05NoNQC+4IbDwRi21E4BmMVcLLAVjQq1Q From: To: , X-OriginalArrivalTime: 28 Aug 2006 07:46:17.0552 (UTC) FILETIME=[0B8F2500:01C6CA76] X-Spam-Score: 0.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have not been following up the GRUU related discussions or read the older GRUU draft. Last week I however studied draft-ietf-sip-gruu-10 and met with a paragraph which I was not unfortunately able to understand: In addition, if the UA is making use of an outbound proxy, the GRUU that is used by the UA MUST be one obtained from a domain that will be visited by the request prior to being routed towards the target in the Request-URI. A request can visit multiple domains if, in addition to an outbound proxy, a UA asks that a request visit additional proxies, identified by additional Route header fields in the request. This can happen when a UA has learned a service route using the mechanisms in RFC 3608 [27]. When using a service route, this requirement (that the GRUU be obtained from a domain that will be visited by the request) it is sufficient to use the GRUU learned in the same registration that delivered the service route. If there is no service route, and the request will visit only the single specified outbound proxy, the UA needs to make sure that the GRUU it used was obtained from the same domain as the outbound proxy. It was especially the last statement which I did not understand at all, and would kindly ask it to be rephrashed: Barring dynamic mechanisms to discover an outbound proxy, such a relationship needs to be configured into the UA. But anyway what is the rationale behind this whole paragraph: - Would routing towards such a GRUU for some reason fail if the request did not visit the domain from which the GRUU was obtained ? If yes, why ?=20 - Or is it just an optimization to avoid the dialog to be routed at first to the outbound proxy which finally resolves the GRUU, just to find out that the request must for its final delivery be forwarded=20 to the domain from which the GRUU was obtained ? I found that the paragraph has been added into the latest version 10 of gruu draft: >* noted that, in the outbound direction, if the home proxy is not on >the original request path, another proxy in that domain needs=20 >to put in=20 >a record-route >that points to it. Provide links to some mechanism which allows a home >proxy to get on the outbound request path > >* clarified that, if an outbound proxy is used, the request has to > visit the domain from which the gruu was obtained before being > forwarded to the party in the r-uri. There are two ways documented > to know this: > > a. using a service route obtained from the same proxy that sent you > a gruu > > b. using an outbound proxy; configuration tells you what domain its > from However I was not able to find the related discussions or any rationale or examples to justify it. Please provide clarifications to me, if you can. A link to the corresponding discussion on the mailing list would also do. Regards, Erkki ____________________________________ Erkki Koivusalo Nokia Mobile Software tel:+358 40 7571197 mailto:erkki.koivusalo@nokia.com ____________________________________=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 29 11:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5Ec-0006oQ-Ph; Tue, 29 Aug 2006 11:10:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5EZ-0006nN-Op; Tue, 29 Aug 2006 11:10:35 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI5ET-0008TX-Kz; Tue, 29 Aug 2006 11:10:35 -0400 Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k7TFAJ5F092087 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 29 Aug 2006 10:10:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <7FEE86DE-A536-4B2A-90D2-7E429B9D2913@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List , sipping , simple@ietf.org, sip-implementors@cs.columbia.edu From: Robert Sparks Date: Tue, 29 Aug 2006 10:10:23 -0500 X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Sip] SIPit 19 registration X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A couple of reminders: SIPit19 registration is open. The event will be Oct 16-20 at the University of New Hampshire InterOperability Laboratory. While the registration deadline is still a few weeks away (9/29), we are already over 70% full. If you are planning to attend and have not yet registered, you should do so soon. Also, please make your hotel reservations early - this is prime leaf- peeping season in New Hampshire and last minute hotels will be very hard to find. See www.sipit.net for more information. RjS _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Tue Aug 29 17:45:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBLF-0002Sl-OJ; Tue, 29 Aug 2006 17:41:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBLF-0002Sg-8o for sip@ietf.org; Tue, 29 Aug 2006 17:41:53 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBLE-0003Av-RR for sip@ietf.org; Tue, 29 Aug 2006 17:41:53 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7TLfgD05605 for ; Tue, 29 Aug 2006 17:41:42 -0400 (EDT) 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: Tue, 29 Aug 2006 16:41:26 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60E24321D@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0C834F94@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-audet-sip-sips-guidelines-03.txt Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQASyJPdA= From: "Samir Srivastava" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Subject: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Here are my comments on this draft in my first reading and I didn't read the call flows. =20 BTW, In the last ad-hoc security meeting consensus on SIPS was without any discussion on Proxy-Require. Looked like me in the minority.=20 This draft has still 8 OPEN ISSUES in 4 iterations and more ISSUES to come /listed below. Group good luck with the plethora of text coming for SIPS :-) 1) Draft is completely silent on the application usages like E911, VoiceMail etc, and other secure transport protocols like DTLS. If DTLS is not considered, it should be stated explicitly. Also we need a separate section for B2BUA (Which some hates). 2) Page 4 Section 3 states "One may then wonder why TLS is mandatory between UA a@A and Proxy A but not between Proxy A and UA b@B. The main reason is that RFC 3261 [RFC3261] was written before [I-D.ietf-sip-outbound]." =20 First the above should be Proxy B. And I would like to bring the following text from 3261, Section 26.3.2.1=20 "Once the registration has been accepted by the registrar, the UA SHOULD leave this TLS connection open provided that the registrar also acts as the proxy server to which requests are sent for users in this administrative domain. The existing TLS connection will be reused to deliver incoming requests to the UA that has just completed registration. Because the UA has already authenticated the server on the other side of the TLS connection, all requests that come over this connection are known to have passed through the proxy server - attackers cannot create spoofed requests that appear to have been sent through that proxy server." Which itself states that TLS connection SHOULD be kept alive. So logic w.r.t. out-bound doesn't make more sense. Though 3261 doesn't cover the case when Proxy and Registrar are not co-resident. 3) UA A, Proxy A etc should have the example names as specified in RFC 2606 And it will be better if trapezoid of 3261 is taken. 4) The Following text from section 3=20 "This means that b@B, upon sending a new Request (e.g., a BYE), will have to use a SIP URI (unless Record-Route is used). This implies that b@B must understand SIPS in the first place, and must also support TLS (again, unless Record-Route happens to be used). " Here strict / loose routing will have different behaviors. Are there any implementation of SIPS with strict Routing? 5) Quoting further from the section 3 "The SIPS scheme implies transitive trust. Obviously, there is nothing that prevents a proxy to cheat and pretend that TLS was used when in fact is was not (see RFC 3261/26.4.4). " Proxies cannot pretend use of TLS, unless two adjacent proxies collaborate. Proxy at next hop can verify the Transport on which packet is received with the transport being put by the proxy in via header. 6) In section 4, =20 "When a proxy is handling the 3XX, it can obviously not indicate anything to the user that it is being redirected from SIPS to SIP: therefore, it is RECOMMENDED that the proxy forwards the 3XX to the UAC instead of recursing, in order to allow for the UAC to take the appropriate action. " Why it is of RECOMMENDED strength? I would rather have it with stronger strength. Implementers / Administrators may _not_ follow this, and still they will comply with this standard (TBD). And UAC has no control. 7) Going further in section 4, where it is describing the potential algorithms for finding the e2e TLS by UAS last bullet reads "If the dialog was "tentatively" secure, it is RECOMMENDED that the security be checked by checking both the Via headers and the Record-route, as described in 26.4.4/RFC 3261. " Record-Route is for the next request in the dialog. Only Via header inspection is needed for this request. Record-Route should be removed. If there is mismatch in these two what should be done? 8)Further in the next paragraph it states=20 "Some proxies MAY be configured to detect uncompliancies and reject unsecure requests. For example, it could inspect Request-URIs, Path, Record-Route, To, From, Contacts and Via headers to enforce SIPS. " Why inspection of From Header ?=20 9) In the next para, it is listing the usage of S/MIME. We have no deployments of S/MIME and issues are listed in 3261 too. Why we keep going to S/MIME now and then? IMHO, we need to have *DEPLOYABLE* security. 10) In Section 5, in para 4 it is referencing the best-effort, No-Security etc configuration policies. Are they covered in Config-framework ? Whether we are going to have the separate config framework for SIPS ? 11) In Section 5, in para 8 it states "It is therefore RECOMMENDED that UACs do not use any transport URI parameters in Contacts in REGISTER" . How does UAC show its preference among TCP/UDP/SCTP/DCCP ? It should not use transport=3Dtls parameter. If it is not allowed, then it should = be stated that 3263 based DNS procedures is the only choice. Look for the scaling now, SIPS/SIP variable with outbound variables etc ? 12) Section 6, gives the example of INVITE, SUBSCRIBE, REFER for the dialog creation etc. What will be done for PUBLISH, which is not a dialog creating request and results in NOTIFY ? 3903 talks about the SIPS but it is silent on when ESC gets the PUBLISH with SIPS and WATCHERS have not subscribed with SIPS. The similar goes with REG-EVENT too. It's a functionality for a new tag (TBD) in Require header, As UA may not want it's secure contact/presence to be distributed over the un-secure channels. It will open up Reg-id, and instance-id to attackers. 13) Section 7 heading " Usage of tls and TLS parameters" is misleading. Atleast to me TLS parameters means cipher-suite, digest, key size etc ? Better can be "Usage of TLS as the transport parameter in SIP URI" =20 14) Section 7, bullet 4 states =20 "In a Request-URI, the transport parameter is useless in general because it is hop-by-hop."=20 It needs more qualifiers w.r.t. Strict/loose Routing etc. 15) The description in Section 9 doesn't consider the text quoted above from 3261, which is quoted above in 2). 16) This draft needs a lot of editorial cleaning too. e.g. 16.1) Section 1, para 2, second sentence has "I" only. 16.2) Section 3, para 5, last sentence " UAs that do not support TLS" should have been "UAS that does not"=20 16.3) Section 4, para 2, second last sentence "Specifically, it says they" should have been "Specifically, it says that they .." 16.4) Section 5, para 1, first sentence "This section describes the registration procedures of SIP versus SIP" Should be ".. SIPS versus SIP" 16.5) Section 5, para 2, first sentence "Since upgrading from SIP to SIPS is allowed it other circumstances" Should be " ... in other circumstances" 16.6) Section 5, Para 3, should list the behavior for " SIP AOR and SIPS Contact" and "SIPS AOR and SIP Contact" explicitly. 16.7) Section 5, Para 6, " SIPS schem:" should be scheme=20 Also third party registration needs some discussion somewhere. 16.8) Section 6, Para 1, second sentence should not contain additional "t" in the following segment " RFC 3261/8.1.1.8, t, if"=20 16.9) Section 6, Para 1, next sentence has two "end" in the following the remote end end not support SIPS" 16.10) Section 7, bullet 1, last sentence "Since thet" should be "Since then" There is more editorial stuff, so I will wait for its cleanup first. Thx Samir =20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 30 09:54:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIQSJ-0005zq-Os; Wed, 30 Aug 2006 09:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIQSI-0005vi-KX for sip@ietf.org; Wed, 30 Aug 2006 09:50:10 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIQSG-0000ai-Bq for sip@ietf.org; Wed, 30 Aug 2006 09:50:10 -0400 Received: from hkaplan [10.0.200.183] by acmepacket.com with ESMTP (SMTPD-9.03) id A78001BC; Wed, 30 Aug 2006 09:49:52 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" , "'IETF SIP List'" Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Date: Wed, 30 Aug 2006 09:49:52 -0400 Message-ID: <047601c6cc3b$2b330ae0$b7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60E24321D@zrc2hxm2.corp.nortel.com> Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQASyJPdAADGf0MA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Samir, comments inline... > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > > BTW, In the last ad-hoc security meeting consensus on SIPS was without > any discussion on Proxy-Require. Looked like me in the minority. What else is there to require? The sips scheme already requires a proxy to follow sips rules. > 5) Quoting further from the section 3 > "The SIPS scheme implies transitive trust. Obviously, there is > nothing that prevents a proxy to cheat and pretend that TLS was used > when in fact is was not (see RFC 3261/26.4.4). " > > Proxies cannot pretend use of TLS, unless two adjacent proxies > collaborate. Proxy at next hop can verify the Transport on which packet > is received with the transport being put by the proxy in via header. Here we go again. :) What you say is true - it takes 2 to conspire, and that should be noted. But of course such a "conspiracy" is not unlikely for this use case. > 9) In the next para, it is listing the usage of S/MIME. We have no > deployments of S/MIME and issues are listed in 3261 too. Why we keep > going to S/MIME now and then? IMHO, we need to have *DEPLOYABLE* > security. If that's the case, then SIPS is moot as well. We have no deployments to speak of, and it has so many caveats one wonders what security it ends up providing beyond a feel-good story for RFCs. (sorry, didn't mean to go down that rat-hole again, but I couldn't help it :) -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 30 17:46:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIXpZ-0000X7-7n; Wed, 30 Aug 2006 17:42:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIXpW-0000X1-Ly for sip@ietf.org; Wed, 30 Aug 2006 17:42:39 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIXpV-0008O3-BC for sip@ietf.org; Wed, 30 Aug 2006 17:42:38 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k7ULaQO19687; Wed, 30 Aug 2006 17:36:27 -0400 (EDT) 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 Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Date: Wed, 30 Aug 2006 16:42:32 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60E2AD961@zrc2hxm2.corp.nortel.com> In-Reply-To: <047601c6cc3b$2b330ae0$b7c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQASyJPdAADGf0MAAnAVkw From: "Samir Srivastava" To: "Hadriel Kaplan" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hadriel, Inline. I am leaving cipher-suite consideration with SIPS, till I publish next version, and we get some consensus. Thx Samir >=20 > What else is there to require? The sips scheme already requires a proxy > to > follow sips rules. Problem is with retargeting etc, which is of the RECOMMENDED strength in the draft. UAC doesn't have control, which I put in another comment. > > Proxies cannot pretend use of TLS, unless two adjacent proxies > > collaborate. Proxy at next hop can verify the Transport on which packet > > is received with the transport being put by the proxy in via header. >=20 > Here we go again. :) What you say is true - it takes 2 to conspire, and > that should be noted. But of course such a "conspiracy" is not unlikely > for > this use case. >=20 You agree two to conspire. So statement in the draft needs the modification. =20 >=20 > If that's the case, then SIPS is moot as well. We have no deployments to > speak of, and it has so many caveats one wonders what security it ends up > providing beyond a feel-good story for RFCs. (sorry, didn't mean to go > down > that rat-hole again, but I couldn't help it :) >=20 S/MIME is older than SIPS :-) =20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 30 20:24:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIaIk-0006g9-49; Wed, 30 Aug 2006 20:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIaIi-0006fS-1E for sip@ietf.org; Wed, 30 Aug 2006 20:20:56 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIaIf-00013y-Mp for sip@ietf.org; Wed, 30 Aug 2006 20:20:56 -0400 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 k7V0EeP05817 for ; Wed, 30 Aug 2006 20:14:40 -0400 (EDT) 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 Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Date: Wed, 30 Aug 2006 19:20:47 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0CC0E3D4@zrc2hxm0.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60E24321D@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQASyJPdAAPa5DUA== From: "Francois Audet" To: "Samir Srivastava" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for your comments Samir. I'll incorporate the obvious ones in my next release. I'm selecting a few ones here that needs further discussion. =20 > 1) Draft is completely silent on the application usages like=20 > E911, VoiceMail etc, and other secure transport protocols=20 > like DTLS. If DTLS is not considered, it should be stated=20 > explicitly.=20 We can not do this before (and if) SIP supports DTLS. As for if SIPS would apply to DTLS, we haven't discussed that on the list yet as it is premature. > Also we need a separate section for B2BUA (Which=20 > some hates). Definitively not. There will be no section on B2BUAs. > 6) In section 4, =20 >=20 > "When a proxy is handling the 3XX, it can > obviously not indicate anything to the user that it is being > redirected from SIPS to SIP: therefore, it is RECOMMENDED that the > proxy forwards the 3XX to the UAC instead of recursing, in order to > allow for the UAC to take the appropriate action. " >=20 > Why it is of RECOMMENDED strength? I would rather have it=20 > with stronger strength. Implementers / Administrators may=20 > _not_ follow this, and still they will comply with this=20 > standard (TBD). And UAC has no control. I'll flag it as oppen issue. But you are correct, if we decide to use RECOMMENDED instead of MUST, we MUST say why (my best guess would be for not diverging unecessarily from RFC 3261). I'd like input from the group. No strong opinion on my side. > 7) Going further in section 4, where it is describing the=20 > potential algorithms for finding the e2e TLS by UAS last bullet reads >=20 > "If the dialog was "tentatively" secure, it is RECOMMENDED=20 > that the security be checked by checking both the Via headers=20 > and the Record-route, as described in 26.4.4/RFC 3261. " >=20 > Record-Route is for the next request in the dialog. Only Via=20 > header inspection is needed for this request. Record-Route=20 > should be removed. > If there is mismatch in these two what should be done? Yeah, I'm not sure why we are talking about Record-Route here. Paul Kyzivat, do you remember? I believe that was your wording. > 10) In Section 5, in para 4 it is referencing the=20 > best-effort, No-Security etc configuration policies. Are they=20 > covered in Config-framework ? Whether we are going to have=20 > the separate config framework for SIPS ? Out-of-scope of this document. > 11) In Section 5, in para 8 it states >=20 > "It is therefore RECOMMENDED that UACs do not use any transport URI > parameters in Contacts in REGISTER" . >=20 > How does UAC show its preference among TCP/UDP/SCTP/DCCP ?=20 It does not show a preference. That's the whole point of the draft. > 12) Section 6, gives the example of INVITE, SUBSCRIBE, REFER=20 > for the dialog creation etc. What will be done for PUBLISH,=20 > which is not a dialog creating request and results in NOTIFY=20 > ? 3903 talks about the SIPS but it is silent on when ESC gets=20 > the PUBLISH with SIPS and WATCHERS have not subscribed with=20 > SIPS. The similar goes with REG-EVENT too. It's a=20 > functionality for a new tag (TBD) in Require header, As UA=20 > may not want it's secure contact/presence to be distributed=20 > over the un-secure channels. It will open up Reg-id, and=20 > instance-id to attackers. Not following you. _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Wed Aug 30 21:22:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIbDX-0001SL-EB; Wed, 30 Aug 2006 21:19:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIbDV-0001SG-Mc for sip@ietf.org; Wed, 30 Aug 2006 21:19:37 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIbDU-0006OJ-DA for sip@ietf.org; Wed, 30 Aug 2006 21:19:37 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7V1JXv13336 for ; Wed, 30 Aug 2006 21:19:33 -0400 (EDT) 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 Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Date: Wed, 30 Aug 2006 20:19:32 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60E2ADB3D@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0CC0E3D4@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQASyJPdAAPa5DUAABpD7w From: "Samir Srivastava" To: "Francois Audet" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Francois, In -line. Thx Samir =20 >=20 > We can not do this before (and if) SIP supports DTLS. As for if > SIPS would apply to DTLS, we haven't discussed that on the list > yet as it is premature. >=20 I agree DTLS is premature. And we know that DTLS does exist as standard track RFC. I posted the use case for this too, Short Page Mode IM. Either we can state that DTLS is considered completely out of scope for SIP or it will be considered in the different document etc. Group needs to close on UDP and DTLS sooner. This is the place where SIPS broken with its current transport-parameter definition. > > Also we need a separate section for B2BUA (Which > > some hates). >=20 > Definitively not. There will be no section on B2BUAs. So you are from the hate camp :-) and SBC/B2BUA is reality. Hadriel what you say? =20 > I'll flag it as oppen issue. But you are correct, if we decide to use > RECOMMENDED instead of MUST, we MUST say why (my best guess would be > for not diverging unecessarily from RFC 3261). >=20 > I'd like input from the group. No strong opinion on my side. >=20 Fine. =20 > > 10) In Section 5, in para 4 it is referencing the > > best-effort, No-Security etc configuration policies. Are they > > covered in Config-framework ? Whether we are going to have > > the separate config framework for SIPS ? >=20 > Out-of-scope of this document. Agreed. We need to see what group thinks on this as a separate draft or taking SIPS to current drafts. I didn't go through config-framework. Config-framework experts? > > > > How does UAC show its preference among TCP/UDP/SCTP/DCCP ? >=20 > It does not show a preference. That's the whole point of the draft. Then we need to state that ONLY RFC3263 defined procedures will be followed for determining the preferences now on. =20 >=20 > > 12) Section 6, gives the example of INVITE, SUBSCRIBE, REFER > > for the dialog creation etc. What will be done for PUBLISH, > > which is not a dialog creating request and results in NOTIFY > > ? 3903 talks about the SIPS but it is silent on when ESC gets > > the PUBLISH with SIPS and WATCHERS have not subscribed with > > SIPS. The similar goes with REG-EVENT too. It's a > > functionality for a new tag (TBD) in Require header, As UA > > may not want it's secure contact/presence to be distributed > > over the un-secure channels. It will open up Reg-id, and > > instance-id to attackers. >=20 > Not following you. Let me rephrase the use case. "If UAC is particular about the security, then he would not like his contacts to be sent over the un-secure channel to the SUBSCRIBERS of REG-EVENT. With the tag (TBD) in Require header, he can control this. " _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 31 00:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIdl3-0007l4-Vx; Thu, 31 Aug 2006 00:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIdl2-0007kA-5T for sip@ietf.org; Thu, 31 Aug 2006 00:02:24 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIdYd-00050i-IJ for sip@ietf.org; Wed, 30 Aug 2006 23:49:37 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id AC4501CC; Wed, 30 Aug 2006 23:49:25 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" , "'IETF SIP List'" Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Date: Wed, 30 Aug 2006 23:49:15 -0400 Message-ID: <068701c6ccb0$6de51d40$b7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60E2AD961@zrc2hxm2.corp.nortel.com> Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQASyJPdAADGf0MAAnAVkwAA/roxA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > > > > What else is there to require? The sips scheme already requires a > proxy > > to > > follow sips rules. > > Problem is with retargeting etc, which is of the RECOMMENDED strength in > the draft. UAC doesn't have control, which I put in another comment. When you say "retargeting" do you mean recursing on a 3xx, or the proxy changing the req-URI due to local routing policies? The former is all the draft says a proxy is recommended not to do from sips to sip. The 3xx case is an interesting situation, since the sips UAS has essentially granted permission to retarget to sip. So you'd need a require header to tell the UAS not to do that, vs. proxy require. If you put a proxy-require, then all the proxies along the path have to support that proxy-require. That would be another barrier to getting sips used. If you meant retarget due to a local routing policy, then the UAC does not have control, and adding a proxy-require won't give it to him. The sips scheme is essentially a faith-based model. The UAC and UAS are putting their faith into the proxies to do the right thing. If a proxy decides it knows better, due to local policy, then that same proxy would know better about a proxy-require and ignore it too. If a proxy retargets to a non-sips target, it probably has some good reason (it thinks) for doing it. For example, it wants to send your call to voicemail which may be directly attached in the same rack, or it wants to send your call to a local PSTN gateway, or to an operator, or whatever. After all there's probably some reason people use retargeting proxies, no? -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 31 01:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIfHe-0005cc-Cd; Thu, 31 Aug 2006 01:40:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIfHd-0005aP-0F for sip@ietf.org; Thu, 31 Aug 2006 01:40:09 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIfHb-0000Ik-LP for sip@ietf.org; Thu, 31 Aug 2006 01:40:08 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 01BC313F869; Thu, 31 Aug 2006 08:39:57 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on lohi.tutpro.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.3 Received: from rautu (eukaryote243.gprs.dnafinland.fi [62.78.106.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 2A0E013F635; Thu, 31 Aug 2006 08:39:47 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id E701CF08A8; Thu, 31 Aug 2006 08:40:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17654.30260.895060.743130@rautu.tutpro.com> Date: Thu, 31 Aug 2006 08:40:04 +0300 From: Juha Heinanen To: "Samir Srivastava" Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60E2ADB3D@zrc2hxm2.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0CC0E3D4@zrc2hxm0.corp.nortel.com> <62B9B0847CC47543B6B3B5E26BD268E60E2ADB3D@zrc2hxm2.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Samir Srivastava writes: > > > Also we need a separate section for B2BUA (Which some hates). > > > > Definitively not. There will be no section on B2BUAs. > > So you are from the hate camp :-) and SBC/B2BUA is reality. Hadriel what > you say? they may be reality, but have nothing to do with this draft. b2bua creates two separate sip dialogs and the draft applies to both separately. whatever mappings you do in your b2bua is not up to standardization. -- juha _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 31 01:58:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIfWr-0006NS-Qc; Thu, 31 Aug 2006 01:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIfWq-0006NL-Rm for sip@ietf.org; Thu, 31 Aug 2006 01:55:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIcdp-0001d9-GH for sip@ietf.org; Wed, 30 Aug 2006 22:50:53 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIcZ2-0005Xy-B2 for sip@ietf.org; Wed, 30 Aug 2006 22:45:57 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.03) id AD560440; Wed, 30 Aug 2006 22:45:42 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" , "'Francois Audet'" , "'IETF SIP List'" Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Date: Wed, 30 Aug 2006 22:45:31 -0400 Message-ID: <068601c6cca7$870fc440$b7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60E2ADB3D@zrc2hxm2.corp.nortel.com> Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQASyJPdAAPa5DUAABpD7wAALNA7A= X-Spam-Score: -2.6 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > > > Definitively not. There will be no section on B2BUAs. > > So you are from the hate camp :-) and SBC/B2BUA is reality. Hadriel what > you say? Oh I agree with Francois. :) They should not be called out in this doc. First there're a lot more b2bua's than just SBCs (for example, many app servers I've seen become b2bua's for some scenarios), second because they're UA's. As a UAS they would do what the UAS does for sips, as a UAC they would do what a UAC does for sips. No matter what you mandate my guess is they will do what their owners want them to do. For example, if their owners want them to send a sips request over IPSEC instead, they will. If their owners want them to act as a sips transparent b2bua, they will. Etc. -hadriel _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 31 02:34:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIg5e-0005t6-Dg; Thu, 31 Aug 2006 02:31:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIg5d-0005sw-BW for Sip@ietf.org; Thu, 31 Aug 2006 02:31:49 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIg5c-0001vX-2m for Sip@ietf.org; Thu, 31 Aug 2006 02:31:49 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 02:31:51 -0400 Received: from 10.128.41.30 ([10.128.41.30]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Aug 2006 06:31:50 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 31 Aug 2006 02:31:36 -0400 Subject: Re: [Sip] question about RFC4240 (NETANN) From: Eric Burger To: , SIP List Message-ID: Thread-Topic: [Sip] question about RFC4240 (NETANN) Thread-Index: AcbMxxuVWjE78ji6EdutvgAWy5cvmw== In-Reply-To: <44EEE39C.3050504@alcatel.be> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Aug 2006 06:31:51.0719 (UTC) FILETIME=[24F45B70:01C6CCC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Oooh - good catch of what looks like an error. From a strict constructionist point of view, the page 7 text is normative, so underbar reigns. However, one can make a very convincing argument the reference to RFC 3066 is normative, hence it should be a hyphen. AFAIK, all implementations to date of RFC 4240 use underbar. Is there enough confusion out there to create an update to 4240? Note that 4240 is not a PS, so this isn't a DS opportunity. On 8/25/06 7:48 AM, "olivier.ro.rousseau@alcatel.be" wrote: > Hello, > > I have a problem with the RFC 4240. > The language parameter is defined in the page 10. > locale-param = "locale=" token > ; per RFC 3066, usually > ; ISO639-1_ISO3166-1 > ; e.g., en, en_US, en_UK, etc. > and is explained in page 7 > locale > Specifies the language and optionally country variant of the > announcement sequence named in the "play=" parameter. RFC 3066 > [9] specifies the locale tag. The locale tag is usually a two- or > three-letter code per ISO 639-1 [11]. The country variant is also > often a two-letter code per ISO 3166-1 [12]. These elements are > concatenated with a single under bar (%x5F) character, such as > "en_CA". > > However whe I look in the RFC3066 I found > Language-Tag = Primary-subtag *( "-" Subtag ) > > Primary-subtag = 1*8ALPHA > > Subtag = 1*8(ALPHA / DIGIT) > > In the RFC3261, the Accept-Langugae is defined as > Accept-Language = "Accept-Language" HCOLON > [ language *(COMMA language) ] > language = language-range *(SEMI accept-param) > language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) > > You can see that one RFC says that a "_" must be used between the two > subtags while the two others says that it must be a "-". > And worse the RFC4240 refers to RFC3066 but uses a different syntax in > its BNF and in its text ( > > Could someone clarify what I should use? > > Thanks and regards, > Olivier > > > > _______________________________________________ > Sip mailing list https://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 31 02:58:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIgTJ-0000td-MM; Thu, 31 Aug 2006 02:56:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIgTH-0000o1-Fa; Thu, 31 Aug 2006 02:56:15 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIgTG-00073A-5v; Thu, 31 Aug 2006 02:56:15 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 02:56:18 -0400 Received: from 10.128.41.30 ([10.128.41.30]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Aug 2006 06:56:16 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 31 Aug 2006 02:55:56 -0400 Subject: Re: [Sip] question about RFC4240 (NETANN) From: Eric Burger To: Sipping Message-ID: Thread-Topic: [Sip] question about RFC4240 (NETANN) Thread-Index: AcbMxxuVWjE78ji6EdutvgAWy5cvmwAA2Y5z In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Aug 2006 06:56:18.0029 (UTC) FILETIME=[8EF181D0:01C6CCCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Whoops - meant to post to SIPPING list. Please follow-up on SIPPING, not SIP. On 8/31/06 2:31 AM, "Eric Burger" wrote: > Oooh - good catch of what looks like an error. From a strict > constructionist point of view, the page 7 text is normative, so underbar > reigns. However, one can make a very convincing argument the reference to > RFC 3066 is normative, hence it should be a hyphen. > > AFAIK, all implementations to date of RFC 4240 use underbar. Is there > enough confusion out there to create an update to 4240? Note that 4240 is > not a PS, so this isn't a DS opportunity. > > > On 8/25/06 7:48 AM, "olivier.ro.rousseau@alcatel.be" > wrote: > >> Hello, >> >> I have a problem with the RFC 4240. >> The language parameter is defined in the page 10. >> locale-param = "locale=" token >> ; per RFC 3066, usually >> ; ISO639-1_ISO3166-1 >> ; e.g., en, en_US, en_UK, etc. >> and is explained in page 7 >> locale >> Specifies the language and optionally country variant of the >> announcement sequence named in the "play=" parameter. RFC 3066 >> [9] specifies the locale tag. The locale tag is usually a two- or >> three-letter code per ISO 639-1 [11]. The country variant is also >> often a two-letter code per ISO 3166-1 [12]. These elements are >> concatenated with a single under bar (%x5F) character, such as >> "en_CA". >> >> However whe I look in the RFC3066 I found >> Language-Tag = Primary-subtag *( "-" Subtag ) >> >> Primary-subtag = 1*8ALPHA >> >> Subtag = 1*8(ALPHA / DIGIT) >> >> In the RFC3261, the Accept-Langugae is defined as >> Accept-Language = "Accept-Language" HCOLON >> [ language *(COMMA language) ] >> language = language-range *(SEMI accept-param) >> language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) >> >> You can see that one RFC says that a "_" must be used between the two >> subtags while the two others says that it must be a "-". >> And worse the RFC4240 refers to RFC3066 but uses a different syntax in >> its BNF and in its text ( >> >> Could someone clarify what I should use? >> >> Thanks and regards, >> Olivier >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.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://www1.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://www1.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 sip-bounces@ietf.org Thu Aug 31 08:59:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIm5w-0002ED-7s; Thu, 31 Aug 2006 08:56:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIm5u-0002E8-6G for sip@ietf.org; Thu, 31 Aug 2006 08:56:30 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIm5s-0002Ji-PO for sip@ietf.org; Thu, 31 Aug 2006 08:56:30 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 14:56:20 +0200 Received: from L-AT7568 ([10.193.5.59]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 14:56:20 +0200 Date: Thu, 31 Aug 2006 14:56:53 +0200 From: "Xavier Marjou" To: pkyzivat@cisco.com Subject: Re: [Sip] GRUU and Mid-Dialog Requests Message-ID: X-Mailer: JBMail 3.2 X-OriginalArrivalTime: 31 Aug 2006 12:56:20.0964 (UTC) FILETIME=[DB4BCA40:01C6CCFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> Let's say UA X has a regular AOR (AOR-X), and 2 GRUU AOR >> (AOR-X;gruu=111 and AOR-X;gruu=222). > The above is a little confusing, because I had assumed "UA X" > referred to a user agent I agree, I should have said that a "user X" has a regular AOR and 2 GRUU AOR. > Updating the To header is currently not allowed. Yes I know it is not currently allowed to update the To URI in the INVITE's response and that an additional UDPATE request is suggested for that. However, I've never really understood why updating the "To" directly in the response is not acceptable, even when I look at the minutes of ietf66 (topic "connected identity", slide 6). > It would be helpful if you would send an example, > containing the messages and headers that you propose using. Basically, what I mean is that a "GRUU" should be an AOR (which is used for routing initial-requests that will reach a contact through a resolution at the home proxy) and should not a remote-target (which is for mid-dialogs requests). I have depicted an illustrative call flow at the end of the mail: flows (3) and (4) are new, the URI in the To header field is updated in (7).(I'm aware that this would also have additional consequences on the registration/proxying steps.) > BUT, the gruu proposal has been baking for a long time, so this is kind of late to consider a major change. I did not realize this point when reviewing the previous draft versions, I admit I only realized this point lately. If there's a rough consensus with the current solution, let's forget it. Xavier Caller Proxy Callee | |(1) REGISTER | | |<--------------------| | |(2) 200 OK | | |-------------------->| | |(3) REGISTER | | |<--------------------| | |(4) 200 OK | | |-------------------->| |(5) INVITE | | |-------------------->| | | |(6) INVITE | | |-------------------->| | |(7) 200 OK | | |<--------------------| |(8) 200 OK | | |<--------------------| | |(9) ACK | | |-------------------->| | | |(10) ACK | | |-------------------->| |(11) SUBSCRIBE | | |-------------------->| | (1) REGISTER sip:example.com SIP/2.0 Supported: gruu To: Callee Contact: ; +sip.instance="" (2) SIP/2.0 200 OK To: Callee ;tag=b88sn Contact: ; gruu="sip:callee@example.com;gruu; opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" ;+sip.instance=""; expires=3600 Content-Length: 0 (3) REGISTER sip:example.com SIP/2.0 Require: gruu To: Callee Contact: ;expires=3600 (4) SIP/2.0 200 OK To: Callee Contact: ;expires=3600 (7) SIP/2.0 200 OK From: Caller ;tag=n88ah To: Callee ;tag=a0z8 CSeq: 1 INVITE Supported: gruu Contact: ; (11) SUBSCRIBE sip:callee@example.com;gruu; opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6; grid=99a SIP/2.0 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 From: Caller ;tag=kkaz- To: Supported: gruu _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 31 11:55:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIoq3-00042O-T1; Thu, 31 Aug 2006 11:52:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIoq2-00040C-1d for sip@ietf.org; Thu, 31 Aug 2006 11:52:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIopy-0004GM-E5 for sip@ietf.org; Thu, 31 Aug 2006 11:52:18 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Aug 2006 08:52:14 -0700 X-IronPort-AV: i="4.08,195,1154934000"; d="scan'208"; a="39263008:sNHT35944828" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7VFqEFZ018290; Thu, 31 Aug 2006 11:52:14 -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.12.10/8.12.6) with ESMTP id k7VFqDdO024264; Thu, 31 Aug 2006 11:52:13 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 11:52:13 -0400 Received: from [161.44.79.176] ([161.44.79.176]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 11:52:13 -0400 Message-ID: <44F705AD.5070204@cisco.com> Date: Thu, 31 Aug 2006 11:52:13 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Xavier Marjou Subject: Re: [Sip] GRUU and Mid-Dialog Requests References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2006 15:52:13.0513 (UTC) FILETIME=[6D1AFB90:01C6CD15] DKIM-Signature: a=rsa-sha1; q=dns; l=5735; t=1157039534; x=1157903534; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20GRUU=20and=20Mid-Dialog=20Requests |To:Xavier=20Marjou=20; X=v=3Dcisco.com=3B=20h=3DBHfEp4ZxQe5icuUoxUyoBEiHrTI=3D; b=SvT4cfwgFwxF+R8r4gxo96idSZV7FUjoz+Bl5VAyQlkmIbTuJXvhLuRTuCgx0Tkl/gOB11xR 5QkcVO71x3d0nNFbJKggS6y5CYZaZ3mYNf94n9+1wLiXbRky/oFj9+38; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Xavier Marjou wrote: >>> Let's say UA X has a regular AOR (AOR-X), and 2 GRUU AOR >>> (AOR-X;gruu=111 and AOR-X;gruu=222). > >> The above is a little confusing, because I had assumed "UA X" >> referred to a user agent > > I agree, I should have said that a "user X" has a regular AOR and 2 GRUU > AOR. > > >> Updating the To header is currently not allowed. > > Yes I know it is not currently allowed to update the To URI in the INVITE's > response and that an additional UDPATE request is suggested for that. > However, I've never really understood why updating the "To" directly in the > response is not acceptable, even when I look at the minutes of ietf66 > (topic "connected identity", slide 6). Well, that is a separate discussion. For the moment we can discuss what you are proposing with the understanding that it assumes the To URI can be changed in the response. >> It would be helpful if you would send an example, >> containing the messages and headers that you propose using. > > Basically, what I mean is that a "GRUU" should be an AOR (which is used for > routing initial-requests that will reach a contact through a resolution at > the home proxy) and should not a remote-target (which is for mid-dialogs > requests). > I have depicted an illustrative call flow at the end of the mail: flows (3) > and (4) are new, the URI in the To header field is updated in (7).(I'm > aware that this would also have additional consequences on the > registration/proxying steps.) You don't show it, but I am assuming that (5) and (6) have To: Callee > BUT, the gruu proposal has been baking for a long time, so this is kind > of late to consider a major change. > > I did not realize this point when reviewing the previous draft versions, I > admit I only realized this point lately. If there's a rough consensus with > the current solution, let's forget it. > > > Xavier > > > > Caller Proxy Callee > | |(1) REGISTER | > | |<--------------------| > | |(2) 200 OK | > | |-------------------->| > | |(3) REGISTER | > | |<--------------------| > | |(4) 200 OK | > | |-------------------->| > |(5) INVITE | | > |-------------------->| | > | |(6) INVITE | > | |-------------------->| > | |(7) 200 OK | > | |<--------------------| > |(8) 200 OK | | > |<--------------------| | > |(9) ACK | | > |-------------------->| | > | |(10) ACK | > | |-------------------->| > |(11) SUBSCRIBE | | > |-------------------->| | > > > > (1) > REGISTER sip:example.com SIP/2.0 > Supported: gruu > To: Callee > > Contact: ; > +sip.instance="" > > > (2) > SIP/2.0 200 OK > To: Callee ;tag=b88sn > > Contact: ; > gruu="sip:callee@example.com;gruu; > opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" > ;+sip.instance=""; > expires=3600 > > Content-Length: 0 > > (3) > REGISTER sip:example.com SIP/2.0 > Require: gruu > > To: Callee opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6> > > Contact: ;expires=3600 > > (4) > SIP/2.0 200 OK > > To: Callee opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6> > > Contact: ;expires=3600 > > (7) > SIP/2.0 200 OK > From: Caller ;tag=n88ah > > To: Callee opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6; > grid=99a>;tag=a0z8 > > CSeq: 1 INVITE > Supported: gruu > Contact: ; > > (11) > > SUBSCRIBE sip:callee@example.com;gruu; > opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6; > grid=99a SIP/2.0 > > Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 > From: Caller ;tag=kkaz- > > To: opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6; > grid=99a> > > Supported: gruu > > _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 31 14:19:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIr5r-0007t5-W8; Thu, 31 Aug 2006 14:16:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIr5q-0007nm-Bs for sip@ietf.org; Thu, 31 Aug 2006 14:16:46 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIr5p-00028v-3m for sip@ietf.org; Thu, 31 Aug 2006 14:16:46 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7VIGfB28968; Thu, 31 Aug 2006 14:16:42 -0400 (EDT) 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 Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Date: Thu, 31 Aug 2006 13:16:26 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60E2AE40F@zrc2hxm2.corp.nortel.com> In-Reply-To: <068601c6cca7$870fc440$b7c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQASyJPdAAPa5DUAABpD7wAALNA7AAIZg7YA== From: "Samir Srivastava" To: "Hadriel Kaplan" , "Francois Audet" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >=20 > Oh I agree with Francois. :) They should not be called out in this doc. > First there're a lot more b2bua's than just SBCs (for example, many app > servers I've seen become b2bua's for some scenarios), second because > they're > UA's. As a UAS they would do what the UAS does for sips, as a UAC they > would do what a UAC does for sips. >=20 > No matter what you mandate my guess is they will do what their owners want > them to do. =20 On the same lines, Then Proxies can do whatever their owners/administrators want them to do too. Thx Samir _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 31 15:41:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsMa-0007sW-JG; Thu, 31 Aug 2006 15:38:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsMY-0007s6-Io for sip@ietf.org; Thu, 31 Aug 2006 15:38:06 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIsMX-0006YW-As for sip@ietf.org; Thu, 31 Aug 2006 15:38:06 -0400 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 k7VJJjg21289; Thu, 31 Aug 2006 15:19:45 -0400 (EDT) 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 Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Date: Thu, 31 Aug 2006 14:19:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0CCAFD4F@zrc2hxm0.corp.nortel.com> In-Reply-To: <068601c6cca7$870fc440$b7c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQASyJPdAAPa5DUAABpD7wAALNA7AAI+MqIA== From: "Francois Audet" To: "Hadriel Kaplan" , "Samir Srivastava" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > Oh I agree with Francois. :) They should not be called out=20 > in this doc. > First there're a lot more b2bua's than just SBCs (for=20 > example, many app servers I've seen become b2bua's for some=20 > scenarios), second because they're UA's. As a UAS they would=20 > do what the UAS does for sips, as a UAC they would do what a=20 > UAC does for sips. =20 >=20 > No matter what you mandate my guess is they will do what=20 > their owners want them to do. For example, if their owners=20 > want them to send a sips request over IPSEC instead, they=20 > will. If their owners want them to act as a sips transparent=20 > b2bua, they will. Etc.=20 Exactly.=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 31 15:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsYM-00011k-Et; Thu, 31 Aug 2006 15:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsY6-0000iZ-PY; Thu, 31 Aug 2006 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIsY6-0001sz-Dl; Thu, 31 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4C43732900; Thu, 31 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GIsY6-0007hm-6V; Thu, 31 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 31 Aug 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Session Initiation Protocol Location Conveyance Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sip-location-conveyance-04.txt Pages : 27 Date : 2006-8-31 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where proxy servers make routing decisions based on the location of the UAC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-location-conveyance-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-location-conveyance-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-31105138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-location-conveyance-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-location-conveyance-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-31105138.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.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-- From sip-bounces@ietf.org Thu Aug 31 17:09:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GItk5-0001Cx-D6; Thu, 31 Aug 2006 17:06:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GItk3-0001BD-ER for sip@ietf.org; Thu, 31 Aug 2006 17:06:27 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GItk2-0005Bo-4y for sip@ietf.org; Thu, 31 Aug 2006 17:06:27 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7VL6Ng16542; Thu, 31 Aug 2006 17:06:23 -0400 (EDT) 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 Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Date: Thu, 31 Aug 2006 16:06:16 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60E315386@zrc2hxm2.corp.nortel.com> In-Reply-To: <068701c6ccb0$6de51d40$b7c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-audet-sip-sips-guidelines-03.txt Thread-Index: AcbGQ50dSIOsDcTKT1GWLWAJ5qfWFQApIduQASyJPdAADGf0MAAnAVkwAA/roxAAIo9ugA== From: "Samir Srivastava" To: "Hadriel Kaplan" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hadriel, In-line. Thx Samir >=20 > When you say "retargeting" do you mean recursing on a 3xx, or the proxy > changing the req-URI due to local routing policies? The former is all the > draft says a proxy is recommended not to do from sips to sip. The 3xx > case > is an interesting situation, since the sips UAS has essentially granted > permission to retarget to sip. So you'd need a require header to tell the > UAS not to do that, vs. proxy require. >=20 > If you put a proxy-require, then all the proxies along the path have to > support that proxy-require. That would be another barrier to getting sips > used. This is same as all the proxies in the path need to support SIPS. So I don't see another barrier. This is a Proxy routing rule. So It will need Proxy-Require. Looks like I am not following you for Require tag. My issue was with the following text of Section 4, where strength was RECOMMENDED. "When a proxy is handling the 3XX, it can obviously not indicate anything to the user that it is being redirected from SIPS to SIP: therefore, it is RECOMMENDED that the proxy forwards the 3XX to the UAC instead of recursing, in order to allow for the UAC to take the appropriate action. " Francois accepted the comment. And will be adding more text etc. >=20 > If you meant retarget due to a local routing policy, then the UAC does not > have control, and adding a proxy-require won't give it to him. The sips > scheme is essentially a faith-based model. The UAC and UAS are putting > their faith into the proxies to do the right thing. If a proxy decides it > knows better, due to local policy, then that same proxy would know better > about a proxy-require and ignore it too. >=20 > If a proxy retargets to a non-sips target, it probably has some good > reason > (it thinks) for doing it. For example, it wants to send your call to > voicemail which may be directly attached in the same rack, or it wants to > send your call to a local PSTN gateway, or to an operator, or whatever. > After all there's probably some reason people use retargeting proxies, no? That's the one reason, we need reverse channel for indicating security employed at each hop to UAC in the response.=20 >=20 > -hadriel >=20 _______________________________________________ Sip mailing list https://www1.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 sip-bounces@ietf.org Thu Aug 31 18:52:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIvMY-0003ZV-Pw; Thu, 31 Aug 2006 18:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIvMW-0003Z4-3z; Thu, 31 Aug 2006 18:50:16 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIvMU-0003sY-OY; Thu, 31 Aug 2006 18:50:16 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k7VMoD93020459; Thu, 31 Aug 2006 15:50:13 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k7VMoDSh020458; Thu, 31 Aug 2006 15:50:13 -0700 Date: Thu, 31 Aug 2006 15:50:13 -0700 Message-Id: <200608312250.k7VMoDSh020458@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.3 (--------------) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4474 on Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4474 Title: Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) Author: J. Peterson, C. Jennings Status: Standards Track Date: August 2006 Mailbox: jon.peterson@neustar.biz, fluffy@cisco.com Pages: 41 Characters: 104952 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-identity-06.txt URL: http://www.rfc-editor.org/rfc/rfc4474.txt The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Sip mailing list https://www1.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